Posts Tagged ‘forms’

Quite often user interface pages will have to be long and scroll. As obvious as it sounds, here is a sketch which supports this. Jason has simply decreased the size of his frames and made them taller. On the same note, one of his sketches also makes use of a zigzagged line. I would guess that has been done to suggest a continuation of sorts, allowing him to communicate that there is more to the page without having to go into detail. I also like the heavy emphasis used on the title. Nice!

Petra has been exploring the idea of using Microsoft Excel for prototyping purposes. Introductory documentation on how to create such a prototype along with the real sample has also been posted online. At first glance, it appears like such a prototype is more suitable for complex data transformations than for GUI design which can be more easily achieved with stronger drawing applications. However, personally I have very little experience with such an approach and it would be interesting to see what others think.

Petra writes:

I created a paper prototype guided by Carolyn Snyder’s excellent book, Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces, for a web application used to book occupancy of the road to do maintenance work, etc. It was a lot of fun testing it on my colleagues and a couple of genuine local users but when it got to testing remote users I thought perhaps I’d try to create an online prototype. I started with PowerPoint but found the macros deficient and a couple of things I wanted to do I couldn’t. I then ordered Effective Prototyping with Excel by Bergen et al, expecting that their prototypes would involve some basic coding but was disappointed to find they didn’t. A programming colleague showed me a couple of very basic code statements in Excel and I realised that with the Control Toolbox widgets, .Visible = True and .Visible = False statements, a couple of If statements, a little googling and a little recording of macros to figure out some code, I could create a pretty workable prototype, albeit only able to handle very specific use cases.

I would guess that not many designers think of specifying or controlling the tabbing order of form elements. It seems that quite often this is the type of interaction which is left alone for the browser to take over and automatically figure out on its own. Most of the time when users press the TAB key, the focus switches between input fields quite well, and if it doesn’t then the mouse is used to correct everything. Hans however, shared with me a user interface sample which clearly makes the tabbing order explicit. He uses a very simple transparent arrow going across form elements in order to indicate the order. It works quite well.

While sketching a user interface with the client, in this example popup overlays or pulldown menus have been drawn up using sticky notes. This technique has been around for a while (as probably seen in a lot of paper prototyping sessions) since it makes perfect common sense. Sticky popups stand out from the background noticeably and also can be easily removed and reattached as desired, which makes them ideal as a solution.

As the design process unfolds on and we begin to tend to the details, form element rules are one area which may be elaborated. From the same designer as in the previous post, comes a sample which specifies form elements in depth. Minoru documents such things as element types, multiple values, default values, character limits, validation rules, etc. Although this is not something that would be typically done in the early phases, such form considerations still can effect the user experience. Thinking about it and putting it down on paper could definitely be worth while.