In theory, a form is the domain of the UX designer - they're the person who should be taking the lead on how it operates and the major components of the "feel". In teams without a UX designer it is normally delegated to the graphic designer for look, and the developer for feel.
Needless to say this can cause conflict, which is why it's normally best to have a form setup that does a solid competent job to start with - that way debate can center around what needs to be done to bring the look into line with the design, rather than the larger arguments about the general operation. Programmers tend to be satisfied with a rather lower standard of interaction and look than designers - how often have you heard programmers complaining about designers wanting pixel-perfect representations of their design? it's not (often) the designer being annoyingly picky, those pixels are important to the aesthetic which influences the mindset of the viewer. Designers often underestimate the complexity involved in forms which can have many visual modes (new, pre-fill, pre-fill with error, client-side error appearance and removal), and ignore the need to maintain consistency in code at the back-end to simplify test suites and reduce change and maintenance burdens, which can sometimes result in visual designs with a wide variety of form layouts (inline, vert labels, horiz labels, with and without fieldset grouping, inline and external section headings, inconsistent confirm/cancel/next/last/back/forward operators). If you don't have a UX person in the team, get the coder in early on the design work so they can cooperate with the graphic designer on issues like that for a much better result. If you're the coder, don't spoil the opportunity by trying to comment on the graphic design (not your specialty, nor your problem) or ignoring the templates that get sent to you for review - getting this stuff sorted early in the process will save immense headaches further down the track. Some designers are delighted when the coder presents them with a solid working forms system - it means they can do a minor bit of work to bring it in line with the aesthetic and then concentrate on more important (to them) issues. > I guess you have posted here kind of vindicates the approach taken by Zend > Framework, > letting the programmer decide the whole form layout from first principles. > I agree that most coders would have settled on a solid forms system and > probably > formed an emotional bond with it, and maybe most would also probably insist > that the design > department give it over to the coders? Does anyone get handed a form and > told - "Here, > make this interact with the server for us." If so, wouldn't it be better > to be able to > first give those designers a set of standards that they can work with, and > that you can also > put online readily? Instead of grumbling that "I will have to completely > rebuild this". > K > > On Mon, 14 Dec 2009 12:08:46 +1300, Richard Clark <[email protected]> > wrote: >> Grids are good for test layouts. Their use in final production is a >> bit iffy at this point. Technically there's no reason not to of >> course, but as you move along in the process some things tend to get a >> bit tricky. A common issue is that you used one grid extent for a >> particular design element (say labels on a horizontal labeled form) >> and then you decide you need more space. Rather than it being a CSS >> change (label) it's a code/template change (change the grid CSS class >> assigned to the form label). >> >> The best bet seems to be to do roughs on the grid, then go through and >> work out which grid extents you used and re-implement them in the >> final CSS with appropriate names. >> >> Keep in mind that grid layouts do not, typically, resize. Arguments >> have been made against the whole grid concept on the basis that they >> don't work well on mobile devices. In my experience, mobile devices >> need their own stylesheet anyway, so as long as you do the renaming >> thing I outlined above you can normally do a perfectly decent mobile >> stylesheet as well. >> > > >> Regarding forms, get a real design - done by someone who really knows >> how forms need to look - and stick with it. A classic failing of stuff >> like RMSforms is the lack of space for error displays, and the poor >> choice of check/radio labeling (those elements tend to have very long >> labels in comparison to other elements). Good form designs take these >> things into account, producing forms that are elegant and readable and >> draw attention to the relevant items. Developers and designers looking >> for a Christmas pressie for themselves could do a lot worse than >> http://rosenfeldmedia.com/books/webforms/ >> >> Other stuff worth reading includes: >> >> * http://www.alistapart.com/articles/inline-validation-in-web-forms/ >> * http://37signals.com/svn/posts/1867-design-decisions-new-signup-form >> >> If you don't already have a solid form presentation layer, you really >> should burn some time on it - get the little details right and make it >> secure, easy and attractive. Some more notes at >> http://phirate.posterous.com/pretty-by-default > >> On Mon, Dec 14, 2009 at 11:41 AM, <[email protected]> wrote: >>> >>> >>> Anyone using any of the new CSS frameworks? I tried 960.gs to see what >>> "separation of concerns" really feels like. Drupal added support I see. >>> Its logical to have a reset.css and a text.css, so why not a layout >>> resource that you dont touch either? Makes fine sense to me, and I was >>> impressed how nice it is to have a stable scaffold for the page, and how >>> simple and fast and readable was my own 'developer' style sheet. I am >>> also >>> looking into the emerging second tier tools now, >>> like http://www.gridsystemgenerator.com/ , >>> or http://wiki.github.com/chriseppstein/compass . As far as PHP for >>> forms >>> goes, I like that Code Igniter allows the designer to specify layout, >>> then I >>> found this posting for Zend Framework: >>> > http://www.zendframeworkexpert.co.uk/2009/06/09/using-a-view-script-to-render-a-zend_form_element/ . >>> Also playing ZF with forms framework like >>> > http://www.rmsjr.com/blog/web-design/rmsforms-a-flexible-tableless-css-forms-framework/ for >>> ZF and generating client side validations ( eg >>> http://jquery.bassistance.de/validate/demo ) that slot into the >>> framework. >>> Evangelising ends. Merry XMAS anyways. >>> >>> -- >>> NZ PHP Users Group: http://groups.google.com/group/nzphpug >>> To post, send email to [email protected] >>> To unsubscribe, send email to >>> [email protected] > > -- > NZ PHP Users Group: http://groups.google.com/group/nzphpug > To post, send email to [email protected] > To unsubscribe, send email to > [email protected] -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
