Sixteenth – Navigare necesse est

This week’s reading was a very complex article that nevertheless ends on a positive and encouraging note. Nevertheless, because in the first part I almost needed a dictionary. Craig Hockenberry’s “Apps vs. The Web” in A List Apart discusses the technical backbone of programming and designing for the Iphone. It is full of terms that I have read the first time: XMLHttpRequest, Cocoa Touch, and NSURLConnection objects, and not mentioning Sparrow framework. But overcoming the lack of knowledge, the article still has a lot to say, even to me. And I am mentioning this not because it has anything to do directly with the questions of this assignment. In the second and also final part, he gives a road map of how to turn a website compliant to the Iphone (instead of thinking in App-terms from the beginning.) And he does it without using words that I do not know. Thus the positive end is that he suggests that even with modest capacities one can turn a website approachable through the screen of an Iphone. And this leads me to the current assignment:

Are menus arguably the most important factor in web design? How important is labeling in creating a clear page hierarchy? How about identifying the menu as links but in a way that doesn’t distract from the rest of the content? When would you make a case for vertical navigation over horizontal navigation?

These are four questions, and each can be answered with few words: Not necessarily, very important, great idea, rarely, I guess.

But longer answers are much better. Especially that through them I can explain the connection that I see between the article and the questions (even if there was no premeditated agenda connecting them.)

To the first two questions I would say that creating easy navigation is what is really important, and it is less interesting how this navigation is created. Either with a good menu or with a strong navigation bar. (For the designer, of course this is a great challenge.) Labeling and hierarchy complements this, since they help the viewer to map the site, and thus navigate easily.

Here I have to mention that in web-related context we use has many words borrowed from seafaring. For example we navigate a site and surf the web. If there are no more expressions like this, I will have to modify this note.

And going back to the questions. The third connects back to the article. To create a menu, which functions as a collection of links, can also help bridging over the gap between viewing the same web site on a computer screen and on an Iphone. No space needed for a separate navigation bar, hence more space remains for content proper. And I would certainly not use a long and wide vertical navigation bar on a small screen. But this answer is very hypothetical, since the navigation bar is part of the design of a site including the navigation bar and its spacing should be dependent on the overall idea of the outlook of the whole site.


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.