Boxes and Arrows: Comments by Anders Ramsay

Anders Ramsay — Fri, 26 Jan 2007 14:52:34 GMT

Good point Adam – I was actually going to make mention of the somewhat testosterone-heavy tilt of the attendees, but then decided against it because I found that the girls were just as much in the thick of discussions and presentations as the boys. I’d say the BarCamp NYC conference had quite a bit of the retreat feel as well, at least compared to those I’ve attended.

Anders Ramsay — Mon, 26 Feb 2007 11:40:20 GMT

Very interesting article. While I think there certainly is something to be said for simulation tools, I have personal experience with several of these tools, including iRise, which I used for designing enterprise apps as an in-house IA at a multinational. First, re. the price, it does not have to be as high as 150K. Our package ran about 50K, which still is an astronomical sum (though not necessarily for a multinational or other large corp, which is a key demographic for iRise) – though packages can run up to 250k (which is what I was told Yahoo paid back in the day for an earlier version of the system.)

While iRise in many ways is very powerful, I ultimately found that it’s key value was in being able to rapidly communicate a new concept. In other words, it worked when part of the early stages of an IKIWISI (I Know It When I See It) requirements gathering model, in which a design was sort of grokked from a set of high-level business requirements, and then I just cranked out a functioning simulation in a day or two, to which stakeholders then responded. *However*, when the proof of concept phase was completed, and time came to actually get into detailed design, it turned out to be far more effective to just whiteboard stuff and return to doing wireframes (either visio or xhtml or flash or some other combination of tools) in collaboration with designers and developers. Why? Well, there are many reasons…

One huge reason was that we found prototyping the functionality in the actual target environment to ultimately be a far beneficial approach. In doing so, we were not only validating the user experience, but also validating the technology.

This is maybe an even bigger reason: at least from my experience, these simulators by and large are not capable of rapidly prototyping ajax functionality or other highly customized interaction design in which things refresh at the element level or animate or whatever, which for me, is an essential component of modern interaction design – for that reason, they may become a constraining factor, since one might only consider design options that the simulator supports.

Anders Ramsay — Fri, 31 Oct 2008 16:29:16 GMT

Martin – thanks for turning me on to PolyPage!

Anders Ramsay — Wed, 12 Nov 2008 21:46:21 GMT

Jonathan – you make some great points here. Yes, not every developer will know XHMTL, but the developers I’m referring to, in terms of the primary target audience, are the ones who build the production version of the application, who would have to know XHTML if that is the production technology. And for those who don’t, such as perhaps back-end developers, they will certainly be able to glean just as much, if not more, than they would learn from a static wireframe or the like. And yes, not everything is communicated by looking at an XHTML file, which is why there still is a need for annotations (though, in my experience, far fewer.)

As far as the dangers of being “too close to the metal” go, that is definitely an issue, and is also why I made a point of stressing the importance of sketching in this methodology, in which we at the outset of evolving an idea are staying as far away from the technology as possible, so as to not be constrained in our thinking. But as time passes and the design funnel narrows, choices have to be made. Your comment about that [UX] designers should never impose their will over a code base is in my opinion only true to a point. Sure, we should definitely not be dictating how developers should code, but at the same time, I think there is a need for UX designers to not be shy little wallflowers, afraid to move beyond all our pretty drawings of the surface layer of the user interface and instead straddle the divide between user experience and technology. If we are building an application with XHTML and related technologies, then XHTML, in the form of well structured markup, is a great place for us to make that connection with the tech side of our team.

Anders Ramsay — Wed, 12 Nov 2008 21:48:12 GMT

Todd – in my case, behavior notes would not be in the source code. They’d instead appear in a separate document, ideally a wiki page. At the top of the wiki page is a link to the corresponding template. Assuming that one followed the best practice of applying IDs to all major content blocks in the XHTML, then in the wiki page, each content block that requires additional notes has its own heading, which is named based on the corresponding content block ID (e.g. notes for ID=”account-options” would have the heading “Account Options.” Underneath that heading are bullet points with the necessary notes, which can optionally link to representations of specific page states. (As an aside, what I’ve found to work best is to have the wiki structure mirror the the application template structure, i.e. one wiki page for each template, with the wiki page hierarchy matching the template hierarchy.)
This is what has worked for me, specifically when working with developers.

ProtoNotes, however, is definitely a powerful alternative to this model.

Anders Ramsay — Mon, 03 Nov 2008 20:22:18 GMT

Aaron – you raise a really important point here. You obviously don’t want to have to wade through unusable (X)HTML to get to the requirements. For that reason, the decision as to who is doing the actual markup will be a team-specific decision based on the respective skill levels of team members. So, if you have someone who doesn’t know the first thing about XHTML and is designing the UX (which IMO in itself is a problem, but that’s a separate issue), then you’d likely have them do something to the effect of what you described above, i.e. just draw a picture of what they want (in PhotoShop or whatever.) More importantly, that drawing (in the model I describe) is just seen as a sketch, and you would then effectively be doing the prototyping. This touches on the issue I discussed about who does what and when – in a traditional waterfall model, the idea is that the front-end developer only does production work (that’s been my experience at least), while here they are collaborating on creating the initial prototype, which then (depending on the project) can evolve into the production build.

Anders Ramsay — Fri, 07 Nov 2008 17:55:11 GMT

Holger – to be clear, I am in no way proposing that prototyping with XHTML somehow is the *best* way to work – I don’t think there is such a thing, as I would instead say that choosing the best design tool is highly contextual decision. *BUT* at the same time, I do think that XHTML prototyping is a far *better* tool (or method) compared to traditional tools like wireframes (and, more recently, prototyping software.)

Re. your comment that one should not go into details too early, not commit to a specific design solution, pls see my earlier comment about how sketching is particularly critical with this method, functioning as that freeform counterpoint to the XHTML prototype. You also said that ”...with each deliverable which is so detailed – a part of our idea expires / dies.” This, in my opinion, is a good thing – design is about making choices,and killing off bad ideas and letting the good ones thrive – but to know which ones to kill off, we have to first road-test them, i.e. prototype them. And if we’re building an app with an XHTML/CSS/JS front-end, there really are few better ways than an XHTML prototype to determine which ideas should live and which should die.