Arrrrcamp ? How many 'r' is that ?
We were at Arrrrcamp in Ghent (Belgium, Europe) on friday October 7th. Arrrrcamp is a Ruby (that make one 'r') and Rails (that makes two) conference, with help from Radiant, a
company making a (thanks Benny) Rails-based CMS (that makes three).
Arrrrcamp is about Rhum, also (so the final 'r') and the whole conference was "pirate-themed", with some speakers taking it very seriously.
The venue and the organization
Before jumping into the first track, a work about the organization : the whole conference looked very Javapolis (sorry, Devoxx) like: fair price, friendly staff, nice venue, multiple tracks with comfy places to discuss/surf/network between the tracks. And food, too. Having the full 8th color 2-people crew onsite allowed us to catch most of the tracks that mattered to us.
Design workflow for Rails - working with designers
By John W Long, creator of RadiantCMS
John Long talk mostly about the importance of design (in the UI meaning, not the general "software design" meaning), rounding it up among some key points:
- put users first (the end users, those you sell it to also, as they can be different people)
- guides users (it lessen your helpdesk tasks)
- avoid surprises (for the user, they will always be bad)
- keep it lightweight (the simplest, the best)
- design is about compromises in between business, design and development - you have to make choices and stand by them
No design? You don't really care about end users?!
While none of his points are ground-breaking, he's an engaging speaker, and those small lists are handy to keep around, just to be sure to stay focus on what matter. John also talk about feedback and iterative design in the spirit of customer development: start with an idea, make some assertions about it, experiment and collect feedback, then repeat, the key aspect being building the smallest thing possible to validate or invalidate your idea.
I also noted a nice summary of the pro's and con's of various prototyping technics:
- White board and flows: Good for brainstorm, bad to take with you
- Wireframe (Balsamiq and the like): Difficult to use during brainstorm (the white board stay more efficient), practical to send after a meeting
- "Hi-fi" mockup (Illustrator, Photoshop, etc): Looks exactly like the future site, but requires a pro to create them and error prone (as modifying it is costly)
- HTML prototyping: Helps with the "final design", but also a good tool for estimation (multiply by four for having the time needed to get the application done)
- Functional (working website): Good for refining when most of the "big points" are settled
While Rails was cited at some moments, most of the talk was about design. One of the only "Rails specific" points was about Serve, a sort of trimmed-down rails with only views, whose objective is to allow designer to work "apart" from the main Rails application, and not having to wait for the backend to be ready. I must say I'm quite dubious about the utility (creating an application with scaffold in Rails is a matter of minutes), but I'll remember this, should it be needed in the future.
Not Rails oriented, but a pretty good talk, with simple, sound advice.