Measuring the Progress of UI

Lately I've been learning ExtJS (which I might write about separately sometime) to try and create a UI for a small application I'm writing for a friend.

The application uses Dancer and KiokuDB. They're both easy to work with and I spent little time working on the backend. The problem lies in the frontend, where I need some UI. I've chosen ExtJS because it has built-in widgets.

I've played with tutorials, general documentation and (tried to) read the not-as-friendly-as-I-thought API. I was able to create a grid, a form and even a viewport. However, it kept feeling like it's stuck. Not stuck as in "this is going slow", but stuck as in "not moving at all".

I don't know how to measure the progress of UI development. Usually, with backend development (which is mostly what I do), I can see the project moving (even if slowly), but here I don't. It reminds me of the stage in your code when you're still guessing yourself on the way you planned out your program, on your algorithms, on your assumptions and supposed requirements. You keep going back to the drawing board, unsure of your project.

Last night I sat once again to try and sketch things out. I decided this time to sketch the usability of the UI instead of the appearance. The difference for me means I think of what would happen instead of how it would look like. I started sketching arrows and write small comments (double click, single click, tab). Things got better, I finally felt like I know my goals, at least the ones in the beginning.

I sat down, wrote a viewport, added a tab panel, added a grid on the first panel and was even able to open and move to a new tab on double click of a record. Pretty cool. At first I was excited about this, but then dejected. Was this progress? How would I know if I made progress just now, or got stuck on something irrelevant?

I assume working on the parts that I already know by heart how to do would be a waste, which is the backend. I should focus on the frontend, that is clear. But should I focus on the panels? On the tabs? On fetching the data? Should I be picking at the grid? Should I be picking at the functionality? What about the layout? Should I be learning how to do everything in ExtJS first? Maybe strengthen a bit on the Javascript side?

I'm feeling quite confused, something that although happens often in life, doesn't occur to me often on the technical side. There are so many things to pick from and I don't know which one is correct. I reckon that is why I keep feeling like I'm making no progress. Maybe I should sketch down all the possible components and then try to assemble a puzzle out of them and then write the functionality. I don't know.

Does anyone have any advice on this?

6 Comments

I'd recommend trying jQuery instead. Lots of UI stuff including widgets, is open source and has an active community.

Gotta love that jQuery meme.


My advice is that you've got to figure out what the "core" operations are from your user's point of view. What are they going to be doing most often? Make the interface stupid simple for that operation, make it work and test it, and then extend it from there. Sort of the "tracer bullet" approach to UI development.


The problem with programmers designing UI is that we are very good at treating all features equally. That is, we tend to make all operations more-or-less just as easy to do as any other. This is wrong: common operations should be easy, very rare operations should be more difficult (if implemented at all), even if the implementation for those operations is extremely similar.


For example, say you're doing a search on a column. 99.9% of the time users will search on column A. But, being a programmer, you know you can give them search on columns B, C, D, E, F, Bar, Baz and Kitchen_Sink as well for essentially no additional code. But to do this is wrong: The user doesn't want to think about which column to search most of the time. They want it to just be "A", without any additional complexity to think about, or even look at.

This is why programmer-developed UIs have the reputation of being overly complicated. It's very easy to implement way more than is needed in the UI. It's hard to trim down the UI to the most efficient set of core operations possible.

Of course, sometimes it's the opposite: An accountant might be perfectly comfortable with a screen filled with boxes and cryptic text, if it's the jargon and the format they expect to see for their core operation.

It's a tough problem, and to solve it you absolutely have to have access to real users to understand their wants, needs, and (not least importantly) their basic emotive response to the interface.

S'easy though isn't it?

The Ext API is logical, well documented and complete.

Where's the prob?

Hey Sawyer X,

I don't know the solution, but I sure am familiar with the problem! I have exactly the same issue when working with ExtJS - I frequently find myself wasting time experimenting with every available configuration option on a widget, even when I know it isn't directly related to the problem I'm trying to solve. I don't know if that's a symptom of the docs not being descriptive enough, or a sign that I'm better suited to server-side development. It kind of reminds me of what happens when I try my hand at digital image editing, I end up spending all my time fiddling with the settings rather than heading towards a clearly defined goal.. maybe that's why I'm a programmer and not a graphic designer :)

I've learnt enough ExtJS to produce some reasonably sized web apps with it (for instance: http://pdonelan.github.com/tarpo) but it's definitely something that continues to frustrate me. Make sure you post a follow-up article if you find a good way forward!

Cheers,

Patrick

Leave a comment

About Sawyer X

user-pic Gots to do the bloggingz