Hi Huw > > In my experience these rules usually apply: > > Do as little as you can. Spend the absolute minimum time on it. > Do just enough (technical work) so that changes can easily be made (this > is usually just a way of including reusable elements). > Everything should be a hack. > Code badly. > Don't reuse any of this work. If you're thinking of re-using it your > prototypes are probably WAY too high fidelity and your code is too good. > Don't worry about your usual technology stack. Static images, HTML and a > little JavaScript (not necessarily your usual framework) are your friend. > It'll be tempting to make a few extra things work. Don't do it. Seriously. > MUST be easy to deploy/share. Sometimes to test we'll need users to > download and look at things, sometimes they'll be able to look at a link > on the web. > Don't worry about making the design perfect, do just enough that the > meaning is clear. > If you need a database/web framework etc. you're probably doing too much. >
<snip> All very excellent points and well said. > Ian, I realise some of these things disagree with with some of the goals > you were hoping for, but hopefully my experience will help a little bit. > > The prototypes for the manage disclosure pages are amazing, really well > done, but I kind of suspect that we could satisfactorily test those > pages with half or even less of the interaction they're currently > capable of. If all our prototypes were going to be that high fidelity > then yes, I can see why things like data persistence etc. would be useful. > You would be surprised how much the managing disclosure prototypes fit in with the points you make above. Until a day or two ago, there was one static html file and a huge blob of javascript to make the various pages hang together. There was a small amount of initial effort to set up some images/icons and other artefacts like launchpad.js containing our yui widgets, but essentially all the rules you mentioned were followed :-) The only things I did to add some structure were to make it easier to tweak things as feedback came in. The mock ups may have looked good from the outside, but I would be ashamed to show the code to someone else, and that to me is one metric which accurately reflects if one has done "too much" engineering on it :-) The only other person who saw it was Jon who also worked on it. Where I was going with my initial post was wanting to make doing the prototype easier by using bits of LP infrastructure not available when using just Javascript and static HTML. All the principals outlined above would be adhered to, but the effort in doing the prototype would be reduced because of the availability of bits of infrastructure which would not have to be otherwise hacked together. I think using HTML5 local storage and mustache will be useful tools to help achieve these goals. Thanks, Ian _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
