Archive for the ‘User interface’ Category

About Brix

Tuesday, March 11th, 2008

Recently I’ve been working on a framework called ‘Brix’, which may interest those who saw my rather hastily-prepared LRUG talk last year. It’s another Ruby web framework – I know, I know – why yet another? Here’s an idea of the philosophy:

  • Ruby needs a component-based web framework, to compete with the likes Tapestry, Seaside and WebObjects
  • Separation, composability and loose coupling of components are more important for agile application development, than rigid separation of View and Controller
  • Components have lives on the client-side as well as the server side, and the server-side needs to handle javascript and css includes, and the instantiation of client-side javascript objects, with the minimum of hassle. The client-side widget tree, in turn, needs to know how to update itself and manage its state.
  • Components take parameters. Components may be nested inside other components. Components may be requested on their own (an Ajax update?) or as part of a bigger component tree. This has big implications for the routing component of a framework.
  • Trying to adhere too religiously to what is typically a muddled interpretation of MVC, is often counter-productive
  • REST is wonderful for APIs, but it is the wrong paradigm for modular web application user interfaces in general. (It copes OK for a CRUD-style UI structure which is closely coupled to the data model, but this isn’t typical of more dynamic web applications in my experience)
  • The back button, and bookmarking, need to work!
  • It would be nice if Google can spider the application, in addition to DHTML clients

The good news is that I’ve found that it’s been relatively easy to get started on, thanks to some of the great tools the Ruby community already has available. I’m only reinventing the parts of the wheel that were creaking badly – for the rest, I’m relying on:

  • Haml (take the hour’s time to learn this, it’s really clean, and especially well suited to programmatic generation of small chunks of DOM tree)
  • Rack ontop of Mongrel
  • ActiveSupport
  • for the time being, ActiveRecord (this is due for the chop once I find something closer to the relational model, or heck, something which can do Class Table Inheritance in something resembling an elegant fashion)
  • Bits cheekily stolen from Merb. I was close to building this entirely ontop of Merb, but I ran into some nasty segfaults on Leopard, it didn’t seem to play well with ActiveSupport, its Router would have needed replacing, and Merb’s controllers, while more lightweight than rails, still got in the way of entirely component-based dispatch. But I’m still really impressed with Merb – It’s like Rails done right – leaner, faster, without the cruft, and with the benefit of hindsight. Easier to extend, too.)

Meet us at LRUG

Thursday, November 8th, 2007

This monday I shall be giving a talk at the London Ruby Users Group. I’ll be giving a tour through our experiences building a modular composable Widget UI framework ontop of Ruby on Rails. Some of the steps we took along the way, problems we encountered, and a tour of the results.

There’s also a juicy debate to be had comparing the REST-driven web application architecture pushed by the Rails project, with our more modular widget-based approach, and in deciding what’s appropriate for your application. For those in the know, comparisons abound with the approach taken by Avi Bryant’s Seaside framework, and the Apotomo plugin already in development for Rails.

The framework comes with a client-side component too, and means of serializing Widgets to constructors for corresponding client-side javascript classes – so the talk may also interest those attempting to do Javascript in an unobtrusive, object-oriented way with Rails.

After that I believe (sincerely hope ;-) ) there are drinks.

The talk is open to all but the venue ask that you Register here; see LRUG for more details.

Of Nouns and Verbs

Thursday, July 26th, 2007

As the site develops we’ve been putting a lot of thought into how to architect things in a suitably general way – to build a playground for users with a set of objects they can play with, and a consistent set of actions they can perform. We found the following approach to be one rather nice way of thinking about it (cue monster diagram which Wordpress refuses to format nicely):

VERB \NOUN STASH (save / collect / organize) STALK (watch / observe / subscribe to) CHAT ABOUT WRITE ABOUT TAG BUY / DOWNLOAD UPLOAD / create
MUSIC / artist / label Save music for download queue; make playlists; organise music library Watch for new releases and events by artist or label; who’s listening to an artist/release/track? Bitch about music Review releases; Interview/profile artists; write music news Categorise music (genres?) Buy music! or download unlimited music if subscriber Upload your own tracks; create mixes and playlists
WORDS Bookmark content; compile your own editorial selections See who’s chatting about a piece Bitch about someone’s news/review/etc   Categorise writing; tell us what it’s about   Upload your own content
CHATS Organise your chat history; bookmark chats Get alerts about new posts in a chat     Categorise chats; tell us what they’re about   Start a chat! Participate!
PEOPLE Friends list; create user groups Get alerts on what friends are up to! Bitch about that guy/gal Profile / interview / write a testimonial about someone Categorize your friends (?)   Sign up! Invite friends!
EVENTS / venues / locations Bookmark events; add to your calendar Watch for new events at a venue / near to a location; Look for new attendees of an event Bitch about that band you saw the other night Review / preview events Categorise events Buy tickets; download flyers Add your own events
PICTURES Make photo galleries   Bitch about that pic your mate took Attach photos to content Tell us what photos are of; tag your friends Download photos and cover art Upload your photos and art

Obviously some of these things are a while off in terms of development – but this should give eager loudplayers an idea of what to expect!

From a software architecture standpoint, I found this an interesting exercise too. On a data modelling / OOD level, our Nouns correspond roughly with classes or data types, and our Verbs with interfaces / method signatures. Of course in practise it’s not quite as simple as the diagram’s layout suggests. But thinking about things in this way does help to identify a useful set of shared interfaces. Rather than keep tacking on additional, distinct modules of functionality (let’s throw in an events section!), we’d like to add nouns and verbs to our playground.

On the user interface level, too, this kind of analysis helped to clarify thinking on how to present a structured, consistent user interface, and how to structure navigation. We have a lot of work to do on this front too, but I feel we’re making great progress. John, our graphic designer and Tim our new recruit and go-to man for UI development, have been battling valiantly with photoshop, css, rails helpers, partials and view code. The task has been to build a suitably general and standardized way of presenting different types of object across the site – music, words, chats, people, artists and so on, all need representing consistently at different sizes and in different contexts, together with icons and links for the actions users can perform on them. It’s been frustrating at times but I think we’re beggining to nail it, and it’ll pay large dividends in the future in simplifying and providing structure for further UI development.