slate blog

A few weeks ago we gave a demo of slate to a group of web app developers here on campus. I sort of expected questions regarding technical issues. “How much load can slate take?”, “Explain this Garnet on Tracks thing…”, or even the “Java is sooo much better. Why didn’t you use Java?”. Well, that didn’t happen. The big thing was “The UI is pretty good. Wish we could do that”.

That sentiment sort of stunned me. Yes, slate has a good, consistent, and hopefully a “get out of the way” UI. But it’s not like it’s some incredible feat. Anyone can pull it off. A couple of tips on UI stuff:

• Let the UI determine your feature set. This is critical. If you can’t work a feature into the UI then you either need to rethink your entire UI or rethink the usefullness of the feature. Whiteboard every new feature starting with the UI. How will someone interact with it? What’s the easiest method to accomplish the task? Not only will you get a cleaner UI you might get a more useful UI because a new more useful feature may come out of your discussions.
• If your gut instinct is that their is something amiss, just a nagging doubt, there probably is something wrong. I think this works in graphic design as well. I’m always stressing, “How does it feel? What does your gut think?” At one point we’ll hit the solution and there is an honest “Wow, that really does feel better” moment. Trust your gut.
• If you, as the developer, find something repetitive and annoying in the interface you’re probably not alone. I think the corollary to this is “The only way to develop a great app is to use the app you’re developing”. I don’t know the number of times with slate where I’ve lived with something for a while, decided to fix it, and noted the issue to our team here. Invariably it’s “Yeah, I found that really annoying too so thanks for fixing it.” Which leads to…
• Talk, talk, talk to your users. Not that we’ve been great about engaging our users directly but with our staff at least I’m always poking and prodding them on UI. It’s the only way to find the flaws and fix them.
• Don’t be afraid to change things. A UI is not perfect the first time you create it. Just look at our screenshots to see what we’ve changed. Learn and change. Don’t be afraid that “People are just used to the way it works now.” That’s a lame excuse. For all you know they’re used to working against your app rather then with it.
• Be consistent with your UI. And once you change make it global. We’ve stuck to some consistent guidelines. Toolbar items are verb noun with the noun being lowercase (e.g. Create page). Component items are plural nouns (e.g. Pages). Input titles with tips following directly afterwords (e.g. Publish on If date chosen is in the future the blog article will stay hidden until then)

UI makes or breaks a project. I think the screenshots and interest they’ve generated are a testament (I hope) to this. Looks cool. Looks polished. Gimme! And don’t just use the excuse “They have to use my product” to skip really thinking about UI. Just do it. Everyone will be happier.

By the way, Amy Hoy is my guiding light on UI stuff. Specifically her When Interface Design Attacks PDF. Good stuff. For our polished icons check out the silk icon set with 700+ great free icons to choose from. Though I do think the ‘home’ icon needs to be tweaked. We added a chimney ;) Chris is in the middle of Designing the Obvious: A Common Sense Approach to Web Application Design which he seems to be enjoying and learning from. Can’t wait to get my mitts on it.

To answer the question “How much load can slate take?” it looks like we can at least do 26 page views per minute. That’s what we averaged this morning for five hours after making the front page of digg with a post about TEH. Feel free to continue digg’ing the story ;)