The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Design guidance

I am developing a web-based,interactive application,for intranet.Our first,UI has not gone down well.Now,i want to involve users to come up with better UI.I have been reding about paper prototypes..can you share your experiences about evolving interface for a web application? Any good resources on net(free)..
thks
omkara

Saturday, July 29, 2006
 
 
Don't bother with paper prototypes for a web app (except for your own design decisions)

Get a template that they're happy with (ie their existing intranet css, images etc)

Draw the screens out (on paper if need be), then create html "mockups" of each screen.....

....by which I mean navigation menus (especially)
....dropdowns with actual meaningful data in them
....listings with ficticious, but real looking data.
....other features
....EVERYTHING should be hardcoded.
(eg. the edit user details screen needs to have all the details for 1 specific user and is loaded when ANY user in the hardcoded list is clicked on).

Copy / Paste as much as possible. Have many screens- In an app where e.g. menus vary depending on login type, have a home page [post login] for each user type. In fact each web page will need duplicating for each user type.

Keep actual functionality to a minimum (or out) - eg save button is a link to screen saying "saved".

Wait for them to request changes. Make it clear you expect / want them to do this. Put (agreed) changes back into design and release again.

It should all be flat HTML / CSS / (minimum) script. you should be able to zip this up and mail it to someone.

Don't be afraid to include DIVs with instructions (eg login user name).

Finally - they need to understand that this is the equivalent of "artist's impression" of a building, NOT the application.

As far as the interface goes - keep it simple. Search / Listing / Edit - all separate screens.
Justin Send private email
Saturday, July 29, 2006
 
 
I would also focus on speed at the expense of eye candy. If your customers are willing to do training, be prepared to deliver ugly pages.

For example, say I had a client that needed to type in names and addresses. Like this...

David, The
123 Main Street
AnyTown, AnyState, 00000

With a spreadsheet, they can type in a name and save it extremely quickly. Your web page(s) should allow them to type in and save a name just as quickly. (Tip: redefine the tab sequence to logically jump from box to box.)

If you have so many graphics or I can't tab from input box to input box such that it takes me ten times longer to do what I need to do, then your web site is horrible.
TheDavid
Monday, July 31, 2006
 
 
Colin Sanson Send private email
Wednesday, August 02, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz