[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Clearer separation of functions and configs depending on view
From:       "Manuel Amador (Rudd-O)" <amadorm () usm ! edu ! ec>
Date:       2003-12-17 0:50:50
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


El mar, 16-12-2003 a las 09:02, Leo Savernik escribió:

> In fact, an HTTP server conceptionally exports an hierarchical file system. 
> Modern HTTPS servers do much more, but this is still the principle of web 
> serving. Just because Microsoft/Mozilla/Gnome are ignoring this principle, it 
> doesn't mean KDE should do so, too.

Let me add to this mail:  Modern Web servers, due to their extraordinary
abilities, give web page developers the possibility to un-hierarchize a
Web site.... Modern frameworks don't even correlate location-on-disk
with hierarchical structure.  The LINK REL="up" tag in HTML documents is
supposed to alleviate that.  If we map the UP button to the location in
the tag (whenver it's present), we would be actually advancing the
purpose of the UP button for regular users, for whom the UP button
should take them UP in the document's hieararchy, NOT the web browser's
on-disk hierarchy.  It would also help us local-disk HOWTO readers,
because ALL HOWTO documents have the UP tag, and we'd be able to
navigate up the subchapters and chapters of every howto.  It'd also help
Weblog groupies, because most weblogs now have support for such a
hierarchy and automatically, by default, let you navigate.

Now the only problem is that doing so would introduce inconsistencies,
because the full implementation would entail that the next and the back
button *should* take you to the next document or last document, per the
LINK REL next and back tags.  But if we implemented that on the next and
back buttons, we'd be out of ways to navigate along our session's web
navigation breadcrumb trail.

Time for a new, discrete toolbar?

> 
> The question is: Should the user be kept from looking and acting on web sites 
> as hierarchies just for the minor threat that they might be confused?
> Hiding functionality is bad because they take the chance for the user to 
> advance (given the fact that most users never ever customize their toolbars. 
> I haven't had to do it either, but usability "improvements" have already 
> wreaked havoc on toolbars for KDE 3.2, so I'll be forced to customize them 
> then). Otherwise, those who will eventually grasp the functionality will 
> happily use it, those who won't will simply ignore it.
> 
> What is especially harmful about KDE's toolbar clear cutting is the excuse of 
> customizability. That way the usability "expert" can turn down any complaints 
> on removals by the default answer "put it back yourself".
> 
> This attitude gradually leads to admittedly very tidy yet very unusable 
> toolbars. Consequently following that move will undoubtfully culminate in the 
> utmost solution of consistency and tidyness: the empty toolbar. The usability 
> "expert" has reached his highest goal in providing the simplest, most 
> understandable, least confusing solution, and the user is fully free from any 
> defaults that might potentially confuse him.
> 
> Toolbars must be designed to accomodate the majority of the users which always 
> has to include the developers. In contrary to CS, for FS no usability group 
> exists that can force the developers to implement and work with dumbed down 
> defaults. It is a necessity that developers use the default settings to the 
> greatest extent possible, because
> - - they get as much care as possible, i. e. testing, maintenance, improvements.
> - - the gap between user settings (those who never customize anything) and 
> developer settings (those which are needed to not make the expert's work a 
> pita) stays as small as possible.
> 
> Otherwise, the current movement for simplification is forcing developers to 
> customize their interface. This has the following disadvantages:
> - - Developers have a harder time to imagine the user environment. This leads to 
> bugs being harder to fix because the developers use customized settings. To 
> make things worse, every developer's settings will slightly vary from each 
> other's, thus maintaining a simplified user interface much more difficult.
> - - Developers won't easily notice bugs/insufficiencies on the dumbed down 
> settings. Therefore, they are much more likely to break. This is a double 
> strike on the users, as they never customize, and now have a broken default.
> 
> >
> [...]
> 
> This response got longer than I anticipated, but it was about time to point 
> out the disadvantages of the "no button is a good button" tendencies that 
> have plagued the usability spirit for quite some time.
> 
> mfg
> 	Leo
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE/3xBnj5jssenUYTsRAn4JAJ9tP8R3dBfxYc4O/G/qIle3hgSWPwCfQLiB
> 1grf2hLl3cLbkNOVm0oa5c4=
> =tDae
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> kde-usability mailing list
> kde-usability@mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
-- 
	Manuel Amador (Rudd-O)
	GPG key ID: keyserver.net C1033CAD

["signature.asc" (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]