Michael Eriksson's Blog

A Swede in Germany

Posts Tagged ‘Design

The common design problem of CSS and position: fixed

leave a comment »

One of the greater* mistakes in the history of the Web is the idiotic CSS instruction “position: fixed”. This instruction causes a piece of the page, usually the top navigation menu, to remain at the same position relative the browser window—instead of relative the web page. Effectively, objects counter-intuitively and annoyingly remain in sight even when the user scrolls.

*My first draft had “greatest”. Then a great number of other web idiocies occurred to me, including such astonishing mistakes as Flash (slowly dying) or the ability for a web site to manipulate the user’s browser history (long gone). Unfortunately, many of the collaborators on and inventors of various Web technologies have been idiots and/or self-serving at the cost of the users. A particular problem, of which “position: fixed” is a good example, is neglecting the interests of and control by the users in favor of the interests of and control by the web sites—quite contrary to the original spirit of HTML.

There are extremely few sensible use cases for this. In fact, of the top of my head, I cannot name a single one. They are bound to exist, but when someone who has spent more than two decades as an avid surfer and sometimes professional web developer cannot name one…

Unfortunately, it is used by more and more sites to implement use cases that are not sensible. Take the aforementioned top navigation menu: This permanently steals screen space from the actual contents of the page without, normally, bringing any benefit to the user. If the menu is present at the top of the page (not window) through e.g. a “position: absolute”, screen space is only lost when looking at the top of the page. After scrolling down, the entire window is used for content, and in the (for most websites) rare cases that the user wants to go back to the top menu, he can do so with one fell click of a button. Nevertheless, these insensible use(case)s have grown so common that it is almost hard to find a website who has not fallen pray to at least one…

This is particularly annoying, because modern displays are almost always* in the 16:9 format, which is far flatter than the old 4:3 or 5:4 formats, and many or most users are underway on notebooks that have smaller screens than desktop displays and often a lower resolution to boot. For instance, I currently write on a notebook with a screen 768 pixel and roughly eight inches tall—a standard reached by many or most “old” monitors in the 1990s (pixel) or even 1980s (inches)! (That my 1366 pixel of width would have been truly outstanding in the 1980s is no comfort in situations like these.)

*Except in the mobile area, where screen space is even more expensive to begin with and the negative effects are even larger…

Not to forget: These 768 pixel must be shared with other items too, including (in my case) the title bar of the browser window, the top and bottom border of the browser window (albeit minimized to 1 pixel), the browser menu, the browser tab bar, and the browser address menu. Many others will have even less space available because they have an OS-taskbar at the bottom of the screen (I have it to the left side) or because they have disabled fewer this-and-that bars in their respective browsers. In the early graphical web browsers of the 1990s there was less such overhead and correspondingly more horizontal screen space.

Take the recent, utterly idiotic*, redesign of FML: There is now a “fixed” top menu that takes up about 140 pixel. Add in the some hundred pixel used for browser bars (and the like), and there is roughly 500 pixel available for the contents (some other users could have less than 400 on the same monitor)—we are effectively back to the ancient VGA resolution! Combine this with a large increase in default spacing and font sizes, and a browser window now shows me two or, on the outside, three entries at a time. Before the redesign, there were twice or thrice as many.

*Other problems include poorly chosen colors, a hard-to-read layout, a chaotic navigation, removal of the paging, … The old version, in contrast, was easy to read, user friendly, relaxing on the eyes, and provided more content per browser window. It might not have won any prizes for avant-garde design; however, that simply should not be a concern for user-friendly website, which should focus on making life easier for the visitors. Indeed, the result is so utterly idiotic that I might give the site up—and had actually planned to make this post about FML… (I re-prioritized in light of encountering unusually many examples of the fixed top navigation menu today—not to mention a smaller-but-still-ill-advised fixed bottom menu on one of my other favorite sites, online dictionary LEO .) As an aside: It is truly depressing that most re-designs of websites decrease usability in favor of some ill-advised attempt to be “flashy”, “cool”, “interesting”, whatnot.

My advice to web developers: Never use this feature. (If some type of manager demands it, explain why it is a user unfriendly to user hostile idea.)

My advice to web surfers: If one of your favorites adds a new one, complain. The chance that someone listens is small, but it exists—and it is the greater the more people complain. (Complaining about all uses encountered would be an unrealistic task.)

Advertisements

Written by michaeleriksson

May 4, 2016 at 11:34 pm

Posted in Uncategorized

Tagged with , , , , , ,

Further notes on WordPress

leave a comment »

As hinted at in my last post, I have been fairly active in exploring WordPress recently. In particular, my excursions into the blogosphere have, until recently, mostly consisted of stumbling onto various blogs during researches, often followed by just reading that blog from beginning to end (skipping entries that turned out to be uninteresting, obviously): This way, I have built up a great mass of read blog entries, but without any continuity, little “compare and contrast”, and no view of the writers side (apart from the very different platform of OpenDiary)—and my recent activities here have given me much deeper insights into WordPress, how different blogs come across, how the writers side works, etc.

A few observations (with a tendency towards griping) on the more technical side:

  1. The whole “theme” thing is done the wrong way around: The themes should not be applied by the authors to their own blogs, but by the readers. This would make for greater consistency, make life easier for the readers, and avoid many annoyances. An article on my website on Separation of content and layout can provide a bit more information about what I mean.

    As an aside, OpenDiary has the same problem—and there I usually used Opera’s UserCSS functionality to just override anything the diarists had concocted. (Note that the themes there are not professionally ready made, like here, but entirely the work of the individual diarists. The result is a high frequency of truly abhorrent designs, with extremely bright and contrasting colors, red text on black backgrounds, and other variations that make the readers eyes hurt.)

  2. The administrative area is abysmally slow—a price to be paid for the extensive functionality. In the weighing of costs and benefits, I am the opinion that WordPress should have been content with less. (Reservation: My time here is sufficiently short that this could conceivably be a temporary shortage in band-width or server capacity. If so, I may have to revise this statement. Under no circumstances, however, would I like to deal with WordPress over a cell phone or a dial-up connection.)

  3. For some reason, HTML text entered with line-breaks is distorted by the artificial addition of paragraphs according to these line-breaks. Really unprofessional: The point of HTML (as opposed to Rich-Text or WYSIWYG editors) is that the actual HTML code can be entered (typically pasted from elsewhere) and be interpreted in the same manner as if it had been written in a plain HTML document.

  4. The Snap previews of links are evil. Compare a discussion on another bloge. I urge my fellow bloggers to follow the advice of that post and turn Snap off. Further, I re-iterate my comment on that post that this is a functionality that should be provided and configurable on the browser level, not on the blog/website level (similar to themes above).

    For users, I have not found any foolproof way to counter this. I tried a few alleged solutions using user-side JavaScript/CSS, but they proved ineffectual for some reason; the same was true for the alleged solution in the Snap FAQ. (And, upon inspection the source code was sufficiently convoluted that it would have taken me more time than I intended to waste to reliably find the right counter-measure.) Currently, I simply have JavaScript turned off per default. This fixes the problem, but can have negative side-effects elsewhere. It may, in particular, be necessary to re-activate it when doing something in the administrative area.

  5. I am puzzled as to why the statistics in the administrative area have a piece of Flash were a conventional image would be expected. There may be some additional functionality present that is not possible with an image, but hardly any that would justify the use of Flash (evil!); in particular, when considering that normal links, CSS, and JavaScript can do most (all?) things that could reasonably be wished for in this context. (Because I have Flash turned off in a very categorical manner, I cannot say what this hypothetical additional functionality would be—or if there is any at all: It could well be that the contents are static, and that the developers simply find generation of Flash easier than of an image.)

Written by michaeleriksson

March 6, 2010 at 3:08 pm

Posted in Uncategorized

Tagged with , , , ,