Archive for February, 2012

Fifteenth – the importance of navigating horizontally

A few weeks ago, we were given an article to read, more importantly to look at. It was “35 creative and effective website headers”  in Design Tutorials. There are some superamazing headers, that for me challenge the very definition of being a header, unless we use a very loose definition of “header-ness.” Some have very minimal navigation, and they liberally interpret horizontal navigation. Within that upper rectangle, called header, there are many non-horizontal solutions to present the navigational choices. And that upper rectangle, called header, is often times not so distinguishable from the rest of the page and not so much upper, than spreading towards the center of the page.

In this post I am to discuss the following question: Is it wiser to go large on a header or have a smaller navigation to allow for original content to sit ‘above the fold?’ This question is connected to the problem that every web designer faces: the economics of the 600 pixel average browser height. How to make an impression in such a restricted space despite the underlying understanding that the web is an infinitely flexible space that can contain theoretically infinite content.

The case study to read was about the change that designers made in CNN’s website when they decided to move the sidebar navigation to the top of the page and turn it into the header. Joshua Porter’s “The Challenges of Moving to Horizontal Navigation” details the transformation and underlines that it involved many word choices and choices of elimination of content. Though this change in the  CNN site constitutes a milestone in web history, I do not think, it serves us a universal lesson. To me it is important, since it is a news site, but for others, who are planning portfolio sites, the case might be different. Providing news means providing information. A navigation bar may help the reader to get the required information in a shorter time, which may work in favor of the site. I guess, this is one of the rare contradictions of the web: the easier and quicker one can get from a site what he or she needs, the longer time and more importantly, the more often, he or she will spend looking and reading that site. And here the presentation of detailed choices in navigation kick in. So the header will be “reduced” to functional buttons in order to leave more space and accent to the news content. The designer can still face it as a challenge and not necessarily as a drag.

But in other cases, the visual look of the header carries as many and as important information as the body itself. I guess, than it is not a bad choice to allow the header to speak for itself instead of introducing the content of the site. This is an example to that from the above mentioned article:

I do not think, it would be a wild exaggeration to say that the header is disproportionally large and that it is great. It barely has any navigation option, yet works as a gate to the inner content of the site.

Having all this above said, I guess, I am opting to give a Solomonic answer to the question above. I would say “It depends.” In case of a site that provides a lot of information, i. e. it tells the news, lists items to sell, lists providers of services, or dishes on the menu, navigation is very important, and headers are likely to be “sacrificed” for the task to “host” the navigation. In case we are talking about a site that is all about the look: a portfolio, online game, and I do not know what else, the header can be treated differently without risking to build a dysfunctional site.


Fourteenth – but not exactly

This week’s readings included an article by Debra Levin Gelman: Designing Web Registration Processes for Kids. Because I am planning to build a site for kids, I had great expectations. And especially because I was going to have a login part, which I did not include in my designs since I was not sure about how to code it, but this is marginal now. I was starting to read this article with the awe that it is really tailored to my interests, but soon I was disillusioned. Exactly when the author got to the second line. She opens with describing why it is difficult to create a login for kids six to eight-year-old. Here is the first argument: “You’re trying to create a digital experience for people who lack the cognitive capacity to understand abstraction.” She is just wrong. Children are capable of understanding abstraction. This is why in day school the teacher can teach them about how to spend money “wisely” by using beans instead of coins. Of course, they understand not every level of abstraction, which makes them not really different form any other age group. As adults have different cognitive levels, children’s vary as well.

The author uses the word abstraction several more times, and the more she uses it, the less I believe that she and I use this word for the same purposes. For example, she believes, that kids would unlikely register if one gives them abstract notions as arguments in favor of registering. “Since kids in this age group find it hard to understand and visualize abstract ideas, it’s important to communicate tangible benefits at the outset of the registration process.” Her argument is that if a Barbie figure or a Lego minifigure “tells” the kid user the benefits of registering, and shows them, how a stored game score, as an example of such benefits,  in the site looks, kids will be more likely to register. I think, also this way, storing game scores remains the same abstract notion, if it was at the beginning, which I doubt. However, the minifigure talking is much more gamy, friendly, and part of the game experience, hence it is more appealing than to look at a rectangle that asks for username and password. So, yes, Gelman is right that such visualisation helps bridging over hardships of understanding, but not abstraction. And there could be many other reasons why the seven-year-old in her example did not want to register and just play than the lack of understanding of the dubious benefit of storing game scores. One of them could have been that he just wanted to play a game.

At a certain point, we also learn that kids are more likely to remember passwords that they make up than those that are web site-generated. Her approach to the permissibility of kids “obvious” choices of usernames like “poopyhead” must come for a very unfortunate experience with a very special sort of kids. I do not intend to design my website having these kinds of kids in my mind…

But the generalizations – I consider them necessary to conceptualize audiences – do not stop there. According to the author, “Kids are pretty smart when it comes to web terminology.” Yet the example of a girl shows that she understands the word submit only if connected to homework and not when it appears on the screen. Another example tells about a boy who at the age of seven could not think that secret code might refer to password. At the same time, they ” don’t like being patronized or talked down to. For example, referring to other players or users as “friends” is presumptuous and a little demeaning.” So neither the “adult” web-words nor the infantile terms work. It is good to have a table that offers a good “vocabulary” to be used on kids sites. However, after reading these examples, I do not really see the point of it. After all, Gelman writes about kids six to eight-year-old as a group lacking the cognitive capacity to understand abstraction. To develop a vocabulary that meets that intellectual level instead of visually supporting the “adult” web vocabulary like being able to recognize the function of the submit button, apparently is not demeaning, at all. Such websites will keep their six to eight-year-old users at the same “fun” and limited cognitive level. More articles like Gelman’s can be written about how to design web sites for this type of audience.

Most importantly, however,”kids in this age group are still slightly egocentric, meaning they have trouble seeing things from other perspectives. As a result, words like “me,” “my,” and “mine” are confusing.” I think this is an unfortunate word choice, even if it is in Latin. And the illustration to this is the case of a six-year-old, who did not understand that he was supposed to fill in his name into the window where it said “my name.” In my mind it has nothing to do with egocentrism. Not with either much or little of it. It has to do with the parent, who allowed the kid to go online without any guidance and whom the author describes as people with “deep-seated fear of sharing personal information.” Maybe such parent would also learn to which websites his or her child visits and limit the web usage from the computer that the child uses.

I guess, it is a waste of bytes to further detail my disagreement with how kids are described here. Also, I had my non-expert common sense to look at web sites designed for kids when I started to think about mine. And it is unnecessary to say, I continue to look at them. The ideas Gelman lists here are great, interesting, useful. But I got them without reading her article, I could just go to these sites and study them. Nevertheless,  articles like this are important and helpful especially for someone who is about to design his or her first web site ever, and even if they provoke me to write posts that are not part of my assignments.



Fourteenth – about depth and perspective

Today’s question is the following: How important is a sense of depth in web design? Can a site be well-designed without the use of the illusion of three dimensional space? At what point is it useful and at what point does it become distracting? Without claiming any expertise in art history, I can establish in this forum that since the late Renaissance even two dimensional art forms, like painting, use perspective. But not always. The question is whether we regard webdesign as just one art media enriching the incessant flow of art history or whatever goes on the computer screen should remain on the computer screen and by no means inserted to larger continuities of human activity.

While I had difficulty in finding the assigned reading on Webdesign Tuts, I did find an interesting article through a link to “How to make a web form in HTML Forms” about creating web forms. It has a three-dimensional picture, which, I find, much more effective than a flow chart. It is a great illustration.

Web Form Working

Based on this picture, I think, the usage of perspective in web design is useful.  Not in the sense of Rafael’s The School of Athens, but in a “web sense:” the design serves content. (In Raphael’s painting the design is the content, this is one of the reasons, we still consider it a superior piece of art.)

I do not have an example at hand, but I can imagine a three-dimensional picture as a the look of a web site. Perspective can add to the experience of the user, since the “artificial” recreation of depth can expand the view that opens to the user. I guess, the golden rule, that the visual has to support the content applies for perspective as well. And again, this is what Raphael need not to concern. He was “just” painting Art.


Thirteenth – tools, aids, and coding

The latest reading, “Useful Coding Tools and JavaScript Libraries For Web Developers” by Vitaly Friedman in Smash Magazine, is a true head spinner. Friedman gives a very long list, and on the top, he apologizes for the length, of – as the title suggests – his list of all kinds of developers’ tools. The list is simply amazing especially for someone who is still a newcomer in this realm. The question to answer pries into the outcome of such a bounty of site-builder tools: do they help professionals, or they introduce coding-illiterates and their poorly designed sites into the market and the web? I think the question, like most very educative questions, carries the answer in itself. However, I also think, not every item in the list supports the argument that these tools make it not only possible but easy to build a website without actually knowing how to code one.

First thing first. I think, tools like the tab generator exemplify how to create something for the web through a bypass around coding. It is like to travel to a country where the language is unknown to the visitor. The visitor buys a travel dictionary that lists ready made sentences. If he or she does not want to have a cup of coffee and a croissant for breakfast as the dictionary suggests, he or she will remain hungry unless he or she learns how to ask properly and pronounce properly bacon and eggs sunny side up with a large glass of orange juice without ice.

Most important lesson of this analogy is that by being able to ask for coffee and croissant as the dictionary instructs, does not make one know how to speak that language. By being able to generate tabs through the aforementioned tools make one capable to operate this tool and create tags. Not to program a website.

Friedman’s list includes tools that help making one’s website accept credit card payments, insert interactive maps, advertise the launching of one’s website. There is also one that helps creating patterns, which can be much more convenient than to use an image and turn it into a pattern (the option I have in my drawing program).

Bottom line is that there are tools that for example allow the programmer not to learn how to draw maps and still insert them into a site and there are others that do the core programming, like where the tabs go, instead of the site creator.

Unlike a baby learning to speak the tongue of his or her mother, when somebody learns a language as a foreign language, he or she gains a view on how that collection of verbal tools works. This is why learning HTML, or for that matter any other computer language, gives more than just the knowledge of the sum of the individual tags that make up the language. It enables the programmer to view a site both as a system of elements and also as a complete whole. By using those programming aids, a site can be built, however, this vision can never be acquired.

Twelfth – after CSS

Since I started this course, I look at coding more often then before, which is not so hard, since before I never looked at the code of any website that I ever visited. This post’s question is about imagining the web before CSS. Again, I have two remarks. One is that until now I was familiar only with the expression BCE. Now, I know there is a historical period, we call BCSS. The other is that given my previous experience, when I imagine the state of the web BCSS and now, when the use of CSS is standard, not very different pictures pop in my mind. I always envision yuppies staring hours at the computer screen, talking in abbreviations, drawing amazing things with the mouse, typing superquick, and never use their mouse to save. (Instead, they always use CTRL+S.) My imagination, of course, develops as I dwell in this course. So now I know, without imagining, that CSS came to relieve HTML from “doing the look.” CSS took over the design and now HTML makes sure, the content and the structure are firm. It allows to create in an even more flexible way than before, when the HTML code encompassed also the parameters of the design. What I can tell in general that sites designed with CSS as opposed those that are not seem to be able to move away from that rather rigid, table-like look. CSS can help creating more pictures that are web-coded and contain text. (As opposed to the HTML documents that seem to have more boxed text with illustrations.)

And in connection to the question, if the web benefits from CSS, I must say, I checked and I found two inter-linked blogs from 2006 and 2007 that argued that CSS was a failure.

But these seem to be a minority. As CSS Positioning 101 by Noah Stokes, the article assigned for this class demonstrates, CSS allows previously unknown liberty in design. Even if half of the article contains code-excerpts, it is written so enthusiastically so I really do not understand how those bloggers could not see the beauty in it.

To close I permit myself to talk historically, again. Two hundred years ago, if one wanted to get rid of toothache, he or she went to the barber. Before electricity, they would use a man powered drill, and since the barber was busy with pulling out the tooth causing the pain, it was the patient who had to pedal a wheel which moved the drill. The tooth was either treated or pulled out, and the patient could leave cured. Since then, dentistry has evolved. Neither two hundred years ago nor now we die of bad teeth as the Egyptian pharaohs did. Yet, I assume, I am not the only one who appreciates the fact that there is an electric drill to help the dentist. And I am not talking about the other technical improvements that dentists use today as opposed to two hundred or two thousand years ago. The aforementioned two blogs argue that CSS fails because most of internet viewers use IE. While that could have been the case in 2006, today it is certainly not. Even internet browsing is subjected to historical change, so why would coding remain the same?

Eleventh – about beautiful sites

Today, the class was asked to look at the interfaces listed at this address: The following questions are to be answered: What is the benefit from creatively displaying your site through layouts such as these? What are the inherent risks? How do you balance both factors? My answer is very timid, since I am not completely sure if my interpretation of interface is correct and we are studying the appearance of the listed web sites.  The website presents many very different sites. Some are full of details, small details, which one can see well and appreciate on a larger screen only. They would remain unnoticeable – as far as I can see, or more precisely cannot see – on a cell phone screen. The whole purpose to show off a designers’ strength in going into little details and taking care of minuscule games embedded in the big picture do not show on a small screen. That is a risk taken when one produces a till-the-details-sophisticated site.

Other websites are very clean and modestly designed. They can be appreciated on different sizes of display. I even like such designs, but they tell more about the designer’s taste than his or her actual technical experience. Looking at it from the opposite angel, a way-too complicated design can betray lack of experience and understanding what code a design requires, if it is possible at all to support such design with a code, and if yes, what the costs of maintaining such a website are.

Connected to this are the menus. Some have very simple menus, others very complex ones. Each item on a menu means an additional page in the site, more size to it. Though in an almost geometrically opposite way that among old-fashioned machos, size does matter on the web. The smaller, the better available, and accessible. Lot of details, lot of information, larger size, slower download.

And maybe one more thing: if we are not talking about a portfolio site, that is we are talking about a site that is not rendered to propagate the capacity of the designer/programmer, the easier for the viewer to understand what the site is about, the better the site will transmit the message it supposed to transmit. Too many details steer the attention away from what is really important. In fact, it can also make the viewer feel lost among the details.

However, one very important point has to be made when trying to summarize the takeaways from this overview. I wish, I will have to balance between too sophisticated design and efficient coding as probably all those creators who stand behind these sites had to do. It will mean that I will be able to create such beautiful visuals that demand sophisticated coding. This is the most important thing I hope to consider once getting to this stage.

Tenth – back to 2001

Jeffrey Zeldman’s 2001 article  From Table Hacks to CSS Layout: A Web Designer’s Journey” in A List Apart is a record of the transition from non-HTML programming to the exclusive use of CSS and also a call to engage with this transition. He calls it the process of detaching “style from content, presentation from structure – design from data. presentation from structure – design from data.” In this article, Zeldman claims to touch only on a tiny portion of the process. Nevertheless, he presents a rather long list of the advantages of CSS coding as opposed to the late 90s-trend. Thus his article is updated if we consider that CSS is now the dominant styling tool for the web. It is outdated, if we consider that his motive, to leave HTML tables behind, is not the case a decade after the article was published. Nevertheless, the case he makes in favor of CSS is valid. All the attributes CSS, even the updated version today, has, allow a more effective design and redesign of any web page. It allows to design for more browsers, even I6 was tested while the article went to publication and since then, the new I6 did perform the CSS box model, not only the article was expanded with a short remark, but its argument gained an additional line of support. The article also testifies to the problems that CSS presented at that time. Zeldman’s argument, including the obstacles he lists, point toward the transformation than in the meanwhile took place. If it says anything about the pace of web evolution is hard to tell. HTML is still around, and many rules will never be invalid. CSS is a development that offers flexible solutions for those problems that the general trend, the separation of content and style hopes to avoid and generates as well. While it might not be the best solution and probably is not the very last in the open-ended history of web design, this is what we have now. Hence, today the menace of training for a fast food restaurant-chain as an alternative to learn CSS is probably unnecessary. In 2012, coders seem to learn CSS as a matter of course. As I read about it during last week, a rather more up-to-date question is, whether what coding designers should familiarize with?