Tag Archive / front-end
Finding a way to frame and hang this quote somewhere in my office space…
Stop drooling over your tools. Start thinking about what you’re building with them and how that’s affecting the world you’re helping create.
— Aral Balkan (@aral) May 10, 2014
The role of a front-end developer is to build interfaces that give the user access to information with the least amount of interference.
— Ivan Wilson (@iwilsonjr) January 28, 2013
Like all things, every story has a beginning. In this case, [Project] Ottawa started with the concept The Information Layer (2009). But what came before this?
Well, it all started in Vancouver, Canada (February 2009) where I saw this film by BERG designer Timo Arnall:
Wireless in the World 2 – https://vimeo.com/12187317
In Wireless in the World, they were imagining wireless networks available in the surrounding environment. Now, this looks like an interesting film. But to me, it was a pretty eye-opening experience. You see, up until this time, I only viewed the Web as being static. That is, something that was only accessible from the comfort of a chair and a desktop computer.
Step back for a moment. Now imagine all those dotted circles representing access points just like one of those desktop computers w/chairs. It would look funny at first but the main point is that each one of those access points is accessing data. They are accessing the same content I am through my desktop computer. If your concept of content is something that is seen through a desktop monitor, what does this do? The concept of having the same content available across all sorts of devices, being available at will – without the constraint of the standard web page format. Even without the author controlling how the information was displayed. The user now has the power not only to access the information but to display it in any fashion he/she wanted.
That idea of information being free, not in the political sense but in accessibility, really changed how I worked. After that film and the lecture, I decided that my job as a front-end developer was not of creating layouts. My job became a person who tried to build products that allowed for easy access to information. Building the layout with excellent code was simply a means to an end. Improving upon the work simple meant improved access to information. Information, in my terms of my work, is equivalent to content.
At this point, I was trying to find a way to explaining this way of thinking. It was only a few months later that I was looking at XSLT or XML transforms. Basically, it is a method of taking data in the form of a XML format and transforming into a format resembling a HTML web page. Well, XML is an open format, anyone can use it at will and modify the information to display it in any form they want. We have RSS feeds – XML format data streams that user can collect data and use. This is where all the dots began to connect. You see, XML or JSON, can carry content/information anywhere with the user applying the formatting.
Going back to this point, I wrote some ideas and sketches which later became The Information Layer. What I realized was that the current UI model was not sufficient – it was simple not granular enough to fully describe what was happening at the time. One of the novel things I did was creating a separation of the Semantic (HTML) Layer from the Information (content) Layer. How important was this? It was very important because it depicted the free flow of information /content. It also displayed the fact that HTML has its own sense of meaning, which was further expanded with HTML5 semantic tags a few years later. This was not a new concept but was not fully realized until now.
And so, that was the beginning. From here, I used this model for building my work.
As I mentioned in an earlier blog entry, Project Ottawa is simply the first practical application of the model. This was revised recently to deal with the concept of content, which will be the main focus point of Project Ottawa/Third Draft.
In February 2009, I went to my first IxDA [Interaction Design Association] Interaction conference in Vancouver, Canada.
A few months later, I created a sketch, made in May 2009 that was translated to the following graphic.
This model, which I call The Information Layer, has been the guiding force in my own work. It has helped me build some of the most successful sites in my career.
To others, it may have been just a theoretical model, but it was built from observations. The observations I had about front-end work and interaction design ideas concerning mobile and data. And it has proven invaluable as a guide in trying to predict how things would turn out in the last couple of years.
But the most important stage was reached this year when the first direct application was started – web application modeling or Project Ottawa. The project itself took The Information Layer and started the path that will eventually lead to a practical application.
However, there is a flaw.
For any model to work, you occasionally go back and test its parts to see what works and what doesn’t. That’s basically how Project Ottawa has been built and it is currently at its second draft (July 2012). But there was one thing that was bothering me – content. I had a better grasp of some of the other layers, but the lowest level of the model (Information Layer) was never really fleshed out. It was more of a “hand-waving” nod to content. There was really no fully defined description of this layer. In the end, it was treated just like the other layers in the model, out of consistency.
But it couldn’t. And those flaws where shown in August and September.
It started with a Karen McGrane lecture at the An Event Apart conference in August. She pointed out a model from the White House digital directive where they had a content model better than my own. After the initial shock, I decided that their model was better and made a revision to The Information Layer to be broken down into three parts – API, Metadata, and Content. In the end, this solves some of the weaknesses in the current Information Layer model.
The other part was some of the feedback from a presentation I gave at Mobile UXCamp DC 2012 in September of Project Ottawa. One of the most important criticisms was that there was little in terms of how changes in content could affect not only a single view/template but also the whole system/application. Likewise, what would happen in the reverse direction – if a change in an application affects content (i.e. responsive design).
So, after a hiatus of two months, I am back at work on Project Ottawa. But this same change meant that the focus on Ottawa will be on building the area that has been its weakness so far – content. With some thought during the hiatus, I have a possible solution that I will introduce next year (1/2/2013) called Content Mapping. At this point, I have only a few sketches (scans from Ottawa skectch/notebook) but I am creating a more refined demo.
But this also means the following:
- I am now starting to work on the Third Draft, for 2013 as planned and
- Project Ottawa will not longer be one model but a collection of integrated models along the blueprint analogy. Each model visualizes each aspect of a web application’s structure and interactions.
And so, the work begins again and Project Ottawa will be going on past its first anniversary in March.
We [FEDs*] have tools for building,
We just don’t have tools for describing what we build.
FEDs* build things – things called web applications. We use code, graphics, etc. We have tools at our disposal to do this. But there is one problem. Architects and engineers can create blueprints and models to display their project.
We have have code and content. But all of this is just words without context. And unless your are willing to search and dig through all the code and comments, its still pretty useless.
What I did with Project Ottawa was take the patterns of building – views, code blocks, scripts – and create visual symbols with reference to these items. Here, the advantage of Ottawa is giving a visual description of the web application. Not just its parts but also its interactions and their relationships among the various parts. Its not a comprehensive view, it just has to be as concise as possible without losing too much precision. And the possibility of manipulating this data to do more interesting things in the future.
* FEDs – Front-End Developers