Architecture against Interface Design?

I recently came across an interesting problem, which I guess is quite a common one for web application developers. I am currently working on a small to middle sized web application, and the development team is using Merb, a nice and neat MVC framework, and are making very good use of the ‘spirit’ and elegance of the conceptual framework provided by this type of architecture, which allows meaningful uris and restfulness. In practice, this results in pretty and simple urls such as /objects/action, or /object/identifier/action: a treat for the eyes, a delight for the mind (if the aesthetic contemplation of urls is your kind of things)!

However, things get a bit messier when different types of relationships are introduced: the particular situation to which I was referring at the beginning of this post is I think an interesting example of such situations. Basically I was building the navigation, which for me always consists of first two main levels, the main one pointing to the ‘management screen’ of each of the main objects of the system, the second one allowing the user to perform actions common to these objects such as view a particular object, edit it create a new one, etc. Although this nicely fits the MVC model as described earlier, discrepancies emerge rather rapidly: Having ‘users’ as a first level navigation item, I wanted to put the roles (as in ‘permission profiles’ that can be applied to users) at the second level after users. However, this would imply ‘cheating’ the MVC architecture, by redirecting the /users/roles url to the actual location of the controller in the MVC architecture, that is to say /roles/ (I hope everybody is still following).

This interestingly illustrate that design decisions based on basic UI principles sometimes contradict conceptually elegant models which are nonetheless very powerful for the design of web applications: These therefore need to allow a certain amount of flexibility for allowing discrepancies between the implicit architecture of the system and its representation in the UI, which seeks to reflect not the neat ordering of the relationships between the objects managed by the system, but the messier interpretation of these by its users.

ps thanks to Glen from epiGenesys. I imagine he may think writing a blog post about this is a bit overkill!

Related posts:

1. Interface Design and Information Architecture for Enterprise Web Applications: Four Simple Principles
2. A Short, Practical Example of User Experience and Interface Design for an Online Drink Ordering Service
3. Outside-in Web Application Development: The advantages of building production-ready static html prototypes as interface mock-ups
4. Social science for software developers – Using tools from social science to inform software design: should software developers also be social scientists?
5. The evolution of the developer’s role: Let’s put all our eggs in the same basket