Enso is Open Source!
Our Products Software Development
You can’t spell “opEN SOurce” without “ENSO”. An amusing coincidence, but appropriate, since from now on Enso is free-as-in-freedom as well as free-as-in-beer. This means anyone can download the source code that we use to build Enso. Anyone can read it, modify it, build Enso from it, and redistribute it to others. We’ve chosen the revised BSD license. This is among the least restrictive licenses, giving you the right to do basically whatever you want with the software; read the link to find out the details.
What does this mean for you?
The opening of the source isn’t going to have any immediate effect on the way Enso works for users. For now, the free Enso installers are remaining unchanged. Users should continue to download those. If your only interest in Enso is as a user, then you can say “Enso is open source now, that’s neat” and go on to the next thing in your reading list. Or check out our brand-new forum. But if you’re interested in how software is made, then keep reading…
Continue reading »
Enso 2.0 Design Thoughts
Design Our Products Software Development
As part of the our move to Mozilla and thinking about a free-as-in-speech Enso, I want to be more transparent with our design directions and goals. Our designs can only benefit by incorporating the criticism and suggestions of the community we have here. Open-source design is a balancing act between making final decisions and finding consensus. We hope to take the lessons that Jono spelled out in his excellent article on successfully humane open-source projects and use them in our own projects.
This post is about the new directions we are taking Enso. If you haven’t done so yet, start by reading about some of the motivations for doing some Enso redesign. In short:
- Enso shouldn’t make you type all of “open” every time
- Enso should be able to open paths and urls
- Enso should support international character input
- Enso should gracefully handle the case where there’s no convenient place to enter text
- Enso shouldn’t require you to type out text, select it, and then run a command when you’d rather run the command and then enter the text (think calculate)
- Enso shouldn’t make you hold down a key while typing lots of characters
We think we’ve solved these problems with our Enso 2.0 redesign. In this post, and possible follow on posts, I’ll walk through the new stuff. I should note that our upcoming prototype will not yet have have all of the features mentioned here.
Continue reading »
Enso Developer Prototype
Our Products Software Development
Ever since we launched Enso, we’ve been getting feedback like this:
— When are you going to come out with the Python API for commands?
— I’m looking for a way to extend Enso.
— Is it is possible to enrich Enso with custom commands?
— I heard there will be support to create your own commands. How far off is this?
— An SDK would be wonderful!
— Being a Python developer, I am very interested in the ability to expand Enso.
— Would you have any available API’s?
The entire Humanized team is extremely proud to announce that the answer to whether is “Yes“, and the answer to when is “Now“! Today marks the release of Enso Developer Prototype, which lets anyone develop commands for Enso. It’s free and it’s available for download.
Continue reading »
Undo Made Easy with Ajax (Part 2): Time-Sensitive Actions
Commentary Software Development
This is the second part of the Undo Made Easy with Ajax series. If you are jumping in late, make sure to check out part 1.
Last time we covered the event queue method, an entirely client-side way of implementing a light-weight, multi-level undo. I mentioned a couple of caveats, including that it does not work in multi-user collaborations, and that it doesn’t work for time-sensitive actions like sending emails. I missed a significant caveat that one of my readers, Alexander Botero-Lowry, pointed out: That two tabs, pointed to the same page, could get out of sync. I wrote about how to solve that issue with cookies.
This time, let’s take a look at solving Undo for time-sensitive actions. In the event queue method, we could wait until the “onunload” event to sync the user’s actions from client-side to server-side. For time-sensitive actions like sending emails, we don’t have that luxury. Worse, email is a push technology. Once an email has been released into the wild tubes of the Internet, it cannot be unsent.* For the unfortunate who hits “send” only to realize that they’ve CC’ed their boss on a steamy love letter, the only things left to hope for are power outages and spam filters. Given how often spam slips past my filters, the outlook is not so good.
Continue reading »
Ten Ways to Make More Humane Open Source Software
Commentary Software Development
A lot of bandwidth has been wasted arguing over the lack of usability in open-source software/free software (henceforth “OSS”). The debate continues at this moment on blogs, forums, and Slashdot comment threads. Some people say that bad usability is endemic to the entire OSS world, while others say that OSS usability is great but that the real problem is the closed-minded users who expect every program to clone Microsoft. Some people contend that UI problems are temporary growing pains, while others say that the OSS development model systematically produces bad UI. Some people even argue that the GPL indirectly rewards software that’s difficult to use! (For the record, I disagree.)
Meanwhile, as these arguments swirl, I’ve been quietly relying on OSS to get my work done. As a professional developer, I spend my most of my time interacting with three programs, all of which are free and open source. I chose each out of dozens of alternatives precisely because I think each of them has the most humane interface in its category. Some OSS isn’t just usable, it’s more humane than the closed-source alternatives. One the other-hand, there’s plenty of OSS which is downright painful.
In an effort to understand usability in the OSS world, I’ve researched the stories behind my favorite — and least favorite — OSS programs. I’ve found a fascinating variety of personalities, design philosophies, and project organizations. Although I’ve only scratched the surface, there are already themes that come up again and again. Because everybody loves top-ten lists, I’ve distilled my observations into a top-ten list of OSS “do”s and “don’t”s.
Continue reading »
Undo Made Easy with Ajax (Part 1.5)
Software Development
This is the second half of the first part of the Undo Made Easy with Ajax series. If you are jumping in late, make sure to check out Part 1.
One of my readers, Alex Botero-Lowry, pointed out a big caveat to the entirely client-side event queue method of implementing Undo: If a user opens a second tab to a page they were viewing, those pages might be out of sync. In the to-do list example, if you delete three to-do items and then open a new tab/window to the same page, those to-do items would still be there. Why? Because the first page knows about the deletes (even though they are uncommitted) and the second does not.
Let’s take the client-side only approach and run with it. There is something nice about not having to mess with the back-end. We can fix the multiple-tab problem by syncing the event queue across all open pages with a cookie.
Continue reading »
Undo Made Easy with Ajax (Part 1)
Design Software Development UI Design Fundamentals
As users, we make mistakes. As designers, we need to design with mistakes in mind, as I argued in my recent article, Never Use a Warning When You Mean Undo. Undo is the ultimate safety net, lending an incredible sense of solidity to an interface. That’s why every desktop application from Word to Photoshop provides multiple-level Undo.
So, then, why are Web apps that provide any sort of Undo so few and far between? The answer I often get is that Undo is hard to implement. I’m here to tell you that it is not.
In this series of blog posts, my goal is to explain just how easy it is to provide Undo functionality. Recently, I gave a preliminary version of this post in a workshop. After giving the front-facing demo of how Undo could work, the audience moved slightly towards the edge of their seats (it’s all you can hope for in the post-lunch session). When I opened the source code and started showing how I implemented undo, the universal response was, “Why are you bothering to explain this implementation? It’s barely anything at all. We’re software engineers. This is easy.”
That’s my point!
Adding Undo to your interfaces profoundly and positively affects the usability of your site. It reduces user frustration, and increases user trust. Both of those outcomes mean that more users continue coming back, which helps your bottom line. Remember: To the user, the interface is the product.
Continue reading »
MoonEdit: Redux
Commentary Software Development
Last year, Aza wrote an article about how MoonEdit enabled us Humanized folks to do some painless collaboration. Someone recently posed the question:
[A year] after that posting, do you still make a lot of use of collaborative editing for recording group talk and crystallizing it into more cohesive documents?
The simple answer is: No.
Continue reading »
Why Software Stinks: Introduction
Software Development
In my recent article Good Service—Bad Software, I made a stink about why open-source software is inhumane and unusable. To all those who read this and thought I was flaming, sorry, I really messed up there; my article sounded like a flame. As some commenters suggested, there are some excellent examples of humane interface design in the open source world. I know that there are forces for good in the open source world; among them, contributors who are unpaid and simply want usable software for their own use. I know that there are people, both in the companies I seemed to be accusing and outside of them, that try to make free and open source software usable.
So I asked myself: why on earth did I actually write this article, when I knew it was going to incite flames? What makes me so passionate that I feel the need to write articles like this? Because, well, software stinks.
Continue reading »
Java vs. Python: XML-RPC
Software Development
I am a happy programmer right now. Working at Humanized is fun for many reasons, but one thing that makes us programmers especially happy is having tools that do what we want instead of getting in our way. Over the past few months we’ve painstakingly set up an excellent development environment for ourselves, and now I think it’s really paying off. Since one of my titles is “toolsmith”, I’ll probably write quite a bit about development tools for this blog.
Continue reading »