Tags:
create new tag
, view all tags

Feature X is/Is not Evil

Whenever this style of statement arises lots of arguments abound, and essentially become Trolls for either side of the argument.

Troll Point: Frames

Discussion Factored out from edit bar should be a preference.

Summary

Summarising pros & cons - percieved or real:

Pros

  • Makes website design more obvious, encourages keeping related things together
  • Makes website more manageable
  • Reduces download times
  • Allows for updating a side bar menu without alot of processing on the server for the body of a page without using java, javascript, DHTML, etc
  • Prevent deep linking - good for some websites so must be good for TWiki?
Cons
  • Website design should not impact user experience. "Don't make me think"
  • Website management should not impact user experience.
  • Layout & Display should be user agnostic "You are not the world" -not the entire world has IFRAMEs, or can support your layout using frames.
  • Prevents a user device mapping the logical structure to a displayable structure suitable for the device easily (DIVs & CSS do a better job here)
  • Doesn't in practice reduce download times - TCP connection issues tend to dominate over the download size of a frame.
  • Prevent deep linking. In TWiki's people would like to be able to address specific comments in their discussions (fine grained addressing). This is far, far deeper linking than you normally get even in sites that allow deep linking. Preventing deep linking is probably against TWiki spirit. (Afterall, what does the InterWikiPlugin implement afterall? smile )

Discussion

Frames were invented as an attempt to reduce download times slightly and make organisation of a web site simpler from a user's perspective. In practice opinions on whether this is actually the case varies:

  • In the case of download times, in the majority of cases this is affected by the time the TCP connection start up takes - the 3 way handshake & initial window growth means that the trivial" small download of the side bar takes almost as long as relatively large page - effectively doubling download time. If you have 4 frames, it takes ~3 times as long to download the page due to connection negotiation. Picture heavy sites (eg for decorative corners) also suffer this problem.
  • Frames don't give you anything for organisation that a templated site can - consider the various TWiki skins that have sidebars, top bars, bottom bars, etc.

As a result if you have a picture heavy website frames will probably not impact your users download speeds in either a significantly positive or negative fashion, nor will you gain significant extra functionality. (With one possible exception. )

The only real question is detraction of users/functionality. Lots of people would like to see TWiki usable on lots of devices - which means very low requirements on end users' devices. The problem with small screens is they're, well, small! Fixed width or height frames on web pages enforce restrictions on who can visit your site. For example, if you decide a top frame height of 150 pixels (about 1 inch on my display), and a bottom frame height of 600 pixels (since you as the site "designer" thing 1024x768 is common enough to warrant it) you instantly exclude anyone with a page height of 600, or 480 from accessing your site. (Or 320 in the case of some PDAs) (eg, are you aware of the 1280x600 display form factor? 1920*1080?)

So you then go OK, I'll choose the left hand nav bar to be 15% of screen width, the top one to be 15% again, etc. If you use frames these sizes are strictly enforced - which means your users might well have to scroll the frame (assuming you did make it scrollable - didn't you?) in order to access the content which should be just "clickable.

The problem is you're making the user painfully aware of the structure for navigation you've chosen. For some websites this is good. In TWiki's case I would argue that keeping people out of the website because they have a PDA, or small widescreen display, or text terminal simply because you chose to use frames is a bad thing.

Finally do they add any user interaction problems ? Yes. If you have a website and click on an external link - where does your content go? In a controlled website you would make sure you had a target attribute of "_top" to replace the contents of the window, not frame. In a TWiki I can easily envision the following scenario: a person puts a link in to outside the TWiki using an a href tag. The result is that target is the frame - that TWiki site then contains from a user's perspective the other site. A second user comes along and then tries to edit that external site, and gets confused.

I can think up a dozen user interaction issues whereby you end up confusing users if you use frames without LOTS of changes to the codebase - which is the last thing you want since TWiki is confusing enough already for the avereage user .

-- MichaelSparks - 14 Jun 2003

Troll Point : No feature is evil, it's use & context that's important

Moved from edit bar should be a preference.

Discussion raising argument...

There is yet another evil from frames. They do not allow to bookmark certain page (deep linking). And I am certain you can find more about why frames are evil on useit.com

-- PeterMasiar - 13 Jun 2003

Oh My! Religion!

Let me take a leaf of of the kind of discussions they have over at PPR - http://c2.com - where there are many XXXIsEvil and XXXIsTheOnlySolution threads.

For every shortcoming X that a method Y has, its usually because the people who build with method Y do so nievely and without consideration for the people who view X as a shortcoming rather than an advantage - and in all probability enver gave any thought to whether it was an advantage or disadvantage.

So its a usability issue not a technology issue. Design it properly and its not a problem.
(Hint: I combine framesets and Wikis but I use IFRAME)

For example, I never bookmark Amazon pages. The URL contains session information over and above the reference to the page. Having develped banking applications, I know that putting user-IDs in the URL is EVIL.

What? Oh, right, context. My religion's heretic is your martyr. It's not evil, its a good technique for tracking sessions, since they use something else when it comes to making the purchase. Amazon encourage you to add the item to you wish-list. That way they cna track what you want and pesteradvise you when something that you might be interested in comes along.

Maybe that site is using frames because they don't want you to do deep linking.
Some sites say that explicitly. Maybe its a limitation of your browser that it can't tell you what the URL's are in the framset. (I've just upgraded to Gnome2 and galeon1.3.3 and there are a lot of features that were in Gnome1 and Galeon 1.2 that are now missing.)
Maybe its that the programmers were the ones who did the "design" of the application and suffered from the all too common failure of imagination since they "know" the technical ins and outs of everything they work with (even if its only MS-Windows).

One of the techniques in UML and XP is that of "Use Case" modeling. How is something to be used? What might the the user do or want to do? Is that a complete description?

That banking application I mentioned, when as a PM I audited what had been built, I found the coders had built what ammounted to a frameset without calling it that, so as to have the menu (think of something a bit like tiger-skin). They thought this "user-friendly" but hadn't bothered to ask any users what they thought before I tried it. So instead of just clicking on the menu I right-clicked "open in new window". Well of course that made a mess of things and showed up all manner of bugs. The coder's reaction was "well you're not supposed to do that, most user's wouldn't". (Want to bet?)

I'd recommend a book by Alan Cooper (yes that Alan Cooper) titled "The Inmates are running the Asylum". No, its not a reference to Poe. After an intordution tnat is an inditement of poor s/w and systems design he describes an approach where the designers make use of different 'actors' (he calls them 'personas') would use and interact with the application.

You can be sure that whatever it is, be it unfermented grape juice as Communion Wine, Harry Potter Books or Swift's "making two blades of wheat grow where only one grew before", to someone it will be a religious issue and they will deem it EVIL. The people in the 1920s who wanted a constitutional change because they thought alcohol was EVIL seemed to deem it less evil than encouraging wholesale flouting of the law and the develpment of organized crime.

I'd rather ask about when something is appropriate or inappropriate.

-- AntonAylward - 14 Jun 2003

I disagree with Michael's division of Pros and Cons. Perhaps because I see TWiki as something other than "just another wiki". To me its an application platform for collaborative applications such as trouble ticket management or document management.

In a purely Wiki context, Michael and Peter are spot on. The use is thinking "here is a topic of interest" and book-marks it.

But the "you are not the world" (it used to be "all the word is not VAX") applies both ways. All the applications that TWiki can be used for are not threaded discussions. Some people seem to be using TWiki purely as a sophisticated content management system, the skin not permitting ordinary users from editing or seeing revisions - it looks just like an informational web site.

I've talked of use-case design. The counterpoint is code-base design.

If we put aside the "general" use of a wiki as a "USENET" with history or "Community Blog" and just think of its role in business, supporting applications such as those I've mentioned, the key issues are very different from those Michael talks about.

The application is there to enhance the productivity and effectveness of the user in his/her role. The appropriateness of the functionality and usability of the interface (how it focuses the user's attention, how it matches the workflow of the task) are what count. If the codebase is ill suited to that then something has to change - quite likely the codebase.

In his book "God And Golem, Inc", Norbert Weiner, one of the pioneers of cybernetics an inventor of that term, rephrasing the bible, said "Render unto Man the things that are Man's, and to the COmputer the things that are the Computer's". We have compilers and high level languages and GIU's to make the comuter do the work and thngs more conventient for the end-user. That is the objective, not preserving a code base.

If, in a business setting, the business needs are best served by an application that uses frames and/or IFRAMES then that is what the business will get.

A while abck I ws called in to consult on a web based application that was stunningly inefficient for various reasons I won't go into. The success of the project depended upon adequate performance of the application. The developers were unwilling to make the changes required. The solution was to install Windows Terminal Server. The company did this. They never dealt with that vendor again. Shortly afterwards the applicatin was replaced by one where the developers were willing to accomodate the specific needs of the company.

I'm sure those of us in industry hasve many similar anecdotes.

I used the term "religion". The unaccomdating "here I stand and will not move" (to mistranlate Luther) attitude is often identified with religion and religious zelouts. This is a higly diversified world. One size, one approach does not fit all. This is the 21st century and we're talking about the diverse culture and varied needs, not an ancient Greek Hotelier.

I'm not saying you have to use frames. They are "not the wiki way" because the wikis we've dealt with in the past have been aplicaitons - usually collaborative discussion forums - that were unsuited to frames.

I'm not saying you don't have to use frames and IFRAMES. For some applications and business needs they may be more suitable.

-- AntonAylward - 14 Jun 2003

Michael said:

    Frames don't give you anything for organisation that a templated site can - consider the various TWiki skins that have sidebars, top bars, bottom bars, etc.

Oh yes they do.

The example I gave - http://www.kutchka.com/kutchka/default.asp - is similar to a Tigerskin but is implemented entirely with static HTML. Tigerskin is not just a skin, it requires a plugin to generate the sidebar.

-- AntonAylward - 14 Jun 2003

Problems with your example site:

  1. Makes an assumption that their banner along the top is more important than their site's content. Why do I say this? On my system that banner takes up fully 1/4 of browser window.
  2. Side bar for menu requires scrolling. If they really wanted their sales link always visible they should've put it with the other static items at the top of the page. That way I'd at least have more than 30% of their side bar visible.
  3. First time I was accessing their site it caused my browser (Konqueror 3.1.1 - the browser in MacOS X is based on the same core code so not that uncommon a codebase).
  4. Menu items have no clear division between them - some are single line, some are not.
  5. Ambiguous use of non-standard icons to denote different content types.
  6. Page content has thick paragraph after thick paragraph separated by almost whole screenfulls of blank space.
    example
    their "products" page contains just 3 words visible when I click on it.
  7. No clear way to return to the "top" page without reloading the site.
  8. Not clear link for sales reps to point people act telling people how to contact them.
  9. Blue text on blue.
  10. The internal links contain pages who's names contain spaces - this directly contravenes internet standards.
  11. Sends cookies on what appears to be a static site for no reason - making the site uncacheable, and hence slower to access.
  12. The links on their no-frames version do not work correctly in a no-frames browser. (Lynx) Worse the errors spewed by the webserver in response state "The parameter is incorrect." as the explanation as to what has gone wrong. (The reason for this appears to be the use of spaces in URLs which can be fixed by the end user knowing they should change the spaces to %20's.
  13. The site using ASP for what appears to be a static site. Why use ASP if the content your serving is static ? Using ASP will make the site slower and uncacheable.

As far as I can tell there is nothing on that site that requires the use of frames. Given their site is relatively low on graphics by using frames all they are doing is limiting the audience that can access their site, demonstrating poor design, and slowing down the first access to their site for users simply to speed up by approximately 4K's worth for their menu. On dialup this "saves" approximately 0.5 seconds, on DSL/Cable (given they claim to be a UK site) this "saves" approximately 0.06 seconds, at the cost of the problems pointed out above.

Overall I view this as a very good example of very poor web design!

-- MichaelSparks - 14 Jun 2003

You're 100% correct Michael, but nothing you say about it being poor site design has anything to do with the religious argument. Poor design is poor design, whatever technology and platform it makes use of. Not everyone has to build their site to some high standard or technical correctness. It works. Until and unless the owners feel that its not doing its job ther is no incentive to refactor it. (Ditto for that matter on the gas-guzzling rusty old SUV my neighbour has ....)

All your points come back to the scenario of some web designer who is focusing on trying to use all of the tehcnology and none of the egonomics. Feature-rich tools like ASP tend to enourage the "whizz-kids" to show off, play a game of "how many of these features can I use at the same time?" Design, an in particular design before decisions about technology, implementation and deployment are made, is important. You've highlighted an attutde where the technology - using all the bits of it - is more important than the design. Quite right. 100%.

If all you want to do is serve up static pages, then why have a web server? As Marcus Ranum pointed out long ago, a series of lines in your /etc/inetd.conf that just cat out the page is enough.

Actually your point #7 is incorrect. There is a menu item to take you "home". That its not labelled "home" is another example of poor design that has nothing to do with the technology, so I'm not faulting you.

Many of your other points are only valid if certian conditions hold. On my browser, Galeon/Mozilla, again a widely used codebase, there is no scrolling. Perhaps with my reading glasses I can handle smaller font sizes than you. Like the man said... PPR:ItDepends ... Just as they didn't design for a no-frames mode, they didn't design to accomodate different window sizes.

But you sure are making this sound like a religious argument.

-- AntonAylward - 14 Jun 2003

> But you sure are making this sound like a religious argument.

Nope - you are the only person who has used that phrase. My comments relate to suitability for the task in hand. There are some sites that I use that make very good use of frames - and many, many, many more where they are not suitably used. If the aim of a site is accessibility - and surely it is with TWiki - then I feel frames are wholey unsuitable.

BTW, if you use cat from inetd for serving web pages you often end up with problems with web proxies and many web browsers... smile

-- MichaelSparks - 14 Jun 2003

Thank you, MichaelSparks for refactoring my commanrd from the edit bar should be a preference page here. I learned what is a troll - and I am rather unhappy my comments could be percived as a flamebait. Sorry about that, folks! I just wanted to express that "using frames is not recommended in general, and I consider it especially agains the wiki way", to write is storter and less bland language. I should know better. frown

English being my not first (or even second) language, I often might use words with slightly shifted meaning (and I consider it rather uncomforting to trying to express my thoughts in basically foreign langugae. Still, I like non-bland language more.

You know me: I am maybe little more noisy for the level of patches which did (not) added to core code, but am never fishing for flamewars. Please next time assume my innocence. smile

And I agree with Anton that to feature is evil per se and each might have proper usage (guns do not kill people - people kill people), but if a newbie does not want to go into deep details, s/he is much better off not using frames, considering tham "evil". And many civilized countries has much lover levels of gun ownership than USA and accordingly lover level of homicides and yes this is not call for another flamewar. wink I just cannot help it - so flame me wink

-- PeterMasiar - 15 Jun 2003

Michael, it seems you're unfamilar with the 'Net jargon "religion", so here is a link to the jargon file entry for 'religious issue'.

I'm saying "It Depends" and "There's More Than One Way To Do It".

Your absolutism is also religious in the sense that it is Religions that go around decreeing that some things are evil and that things shouldn't be done under any circumstances, and dismisisng such extenuating circumstances as "business drivers", budget and that the solution may be adequate for the needs of the situation.

OBTW: Using cat has a very great advantage. There's complex no server to hack. That may outweigh any disadvantages in some circumstances. As I said, "It all depends".

-- AntonAylward - 15 Jun 2003

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2003-08-14 - DavidBright
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.