I ‘ve been working on web applications for a few years now, and while I don’t claim to be an expert on the subject, I have gotten my hands dirty in building apps on all sorts of different web frameworks (about 8 now). After being exposed to the UX community for nearly a year now, I realized just how diverse this group is, though most of us work on UX for websites. I’m curious to know just how much UX people understand web frameworks, and its impact on the web development community.
In this post, I’m going to share a bit about my background as a software developer, in hopes to shed some light on how web frameworks impact UX-related work. My hope is to generate some understanding between the two camps (UX folks and programmers) so that we can attain a common goal, which is to build applications and services that are robust, functional, and satisfying.
Since this post is aimed towards a general UX audience, I’m going to avoid talking about the philosophy and thinking behind UX. I think there is enough literature on that subject for software-types who are interested in UX. Instead, I will talk about the other side of the fence – what are software developers like? What makes them tick? Why do they do the things they do? And why can’t we get along sometimes?
The Philosophy of Features and Functions
In Cooper’s book titled, “The Inmates are Running the Asylum“, he describes developers who commonly make poor assumptions about users, forcing technology on them in ways that cause fustration and confusion. This is partly because of the kind of thinking and immersion that often goes on in building a software application is very counter cultural, and it’s hard to appreciate, let alone design applications for users, while you’re focussing on building applications.
Software developers are extremely technical people, and the whole work of building software doesn’t just include knowledge and skill, but includes other factors such as the culture of working in software teams, physical environments, system-allegiance (open source vs. microsoft, oracle vs. mysql, etc.), organizational structures, the nature of how projects run, and relationships with clients and/or internal staff.
From this tacit and specialized knowledge, software people can often wield enormous influence. It is not difficult to find groups of software people that are isolated or contained, in an environment that they require to do what they feel is needed to build software. Usually, this involves having a computer to yourself, a space that is condusive for software development, some degree of flexibility in terms of work schedules, and close proximity to teammates (though this isn’t always the case, with certain software practices).
A new recruit who is given his/her table in the software group will feel removed from marketing, sales, admin, human resource, and management. There are of course, exceptions to this – but there are many companies that operate in this fashion, and it seems to work fine for a lot of people.
While this kind of environment is good for producing application functionality, it reinforces the idea that functionality is the ultimate goal – thus there is this effort to provide for and manage the production of “function”, since this will dictate the health of the team. Software people are rewarded on producing functionality, after all, and to this end they will deliver. This is why feature creep is so common – software people gain rewards from building features, intrinsically or otherwise.
Frameworks are Bespoke
This is where web frameworks come in. Because of the increasing demand for software of all kinds, there is tremendous pressure on developers to build applications fast enough that meet the requirements, and yet robust and scalable. Software teams often use web frameworks to leverage on, because building applications from scratch can be costly and time consuming.
However, while most frameworks are actually built with enormous flexibility in mind, they are actually bespoke (standalone, designed for a specific purpose), and will dictate the kind of thinking and culture that revolves around the building of an application.
One of the first web frameworks that I started using was Apache Struts, which is based on Java. It was an amazing platform that enabled me to be in control of so many things about an application, such as databases, internationalization (multiple language support), file organization, and templating. However, it required a steep learning curve, and once I managed to integrate all my knowledge and build a software, my time was consumed and wrapped up in making sure everything was built and designed with the framework in mind.
I had to be extremely careful that certain configuration files were in the right place, that I didn’t misunderstand the “thinking” behind the Struts framework that governed the way applications were meant to be built on the framework. And because Struts was based on Java, it also had to have a philosophy compatible with “The Java Way” of doing things, which meant that you also needed to appreciate things beyond the framework itself.
When software platforms change, or when teams migrate to different web frameworks, this thinking needs to change. It is almost like a paradigm shift, because Java does not work like PHP or Ruby, and Oracle is quite different to MySQL and so on. So when technologies change, web frameworks follow suit.
This is why some folks advocate that interaction designers and software developers should not be the same person – building software takes up a lot of effort.
Bridging the Gap
Understanding the differences between web frameworks can be a boon (no pun intended) for UX practitioners who work closely with software people. This of course implies that they appreciate the thinking and the culture behind them. The reason why I focus on frameworks and not just any software technology in general is because it’s a very common way of building web applications today, and are the enabling platforms for interface developers and designers – just that they will probably only see the tip of the iceberg through template files (e.g. Smarty templates, HTML, CSS), Javascript and images.
37Signals popularized the notion that “the interface is the application”. This can lead to some serious misconceptions about the way applications should be built. In the software world, the whole is usually more than the sum of its parts. Interfaces depend on not just images, HTML, Javascript and CSS alone, but on the architecture it sits on – database, servers, and very often, the web framework.
Because of this, software developers are constantly aware of the separation between “view” and “logic”, which are synonymous with the relationship between designer and programmer, interface and framework, user and system. While this makes it very clean and organized, the decoupling of these relationships can sometimes create an artificial “gap”, which can lead to animosity between designers and programmers.
This is the point that is most crucial to both sides. Having a shared understanding of how interfaces are designed and how frameworks run will lead to better software. As an example, certain systems are designed to handle textual data better than others, certain frameworks are designed for certain types of platforms (Struts and Spring for enterprise apps, Django for content heavy/layout-based apps), and the way you build an application will dictate the performance of an application on the interface.
This is only the beginning
We’re only beginning to scratch the surface here, since the discussion on what a web framework really looks like and how do applications get built with it will require more time than this post can afford. But it’s a good start, and no doubt UX practitioners and programmers will share a partnership around technologies for a long time to come. My hope is that we’ll be able to build a better understanding of how this partnership can be built, strengthened, and communicated.
References and related links:
