A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
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)..
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.
....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.
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...
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.
Monday, July 31, 2006
Take a look at the idea of Inductive User Interface design.
Here a couple of starting points.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz