>Peter Boersma wrote: Writing long specs is what I try to avoid at all costs.
>> > > Putting the bare minimum of specifications in the wireframes >(with some room >> for notes), and deferring details of the working of global elements to >> seperate lean & mean documents is my preferred way to go. > >***[PGP] I can see from your title that you work on Web sites. Web >sites--because of the limits of the technology behind them--are typically >very simple stuff from an interaction design viewpoint. It's mainly >navigation. I predominantly work on very complex desktop software and Web >applications implemented as binary code for specific platforms. If I didn't >write detailed specs, I'd basically be telling the engineers to implement >interactions in any way they liked. When I design Web applications >implemented in HTML, I still write specs, but obviously they're >comparatively brief. I don't generally work on Web sites, but in that case, >annotated wireframes might be sufficient.
I think you are downplaying web apps here.
Having done software testing on web apps, handheld device apps which
communicated with servers, and complex desktop apps with and without
server access features, there really isn't much difference on the QE
end. Web apps are a heck of a lot more than just HTML navigation,
once you throw Java and database interactions in.
There does tend to be a level of difference, but it's in the "number
of features" arena, not in the complexity or sophistication. This
limits the user interactions, but it's more because of the Internet
chokepoint -- how much you can depend on the user's system to do and
how much data you can get to and from the server without delaying the
user too long -- than because of limits on what can be done overall;
it's an economic limit more than a programmatic one. The specs --
both Dev and UI -- have tended to be equivalently thick and complex
(or often, just as sparse and minimal and devoid of the content QE
needs to not have to flail around in the dark).