Reported by: Anonymous

 

Duration: 

 

Supplier: Personal Computer Manufacturers

 

Alias: 

 

Product: 

 

Bug: Inability to copy files to writeable CD's or DVD's exactly as you copy to any other disk.  Need for special software and methodology.  Commonplace inability to write to a disk that is not full, just because some data was previously written.

 

Class of Error: Failure to fully implement the GUI

 

Proposed Fix: Writable CD's and DVD's should behave just like any other disk.  Additional software should never be needed to copy files (other than a device driver, if required).  Dragging files to the disk should write those files.  Dragging more files should also write those files.  Multisession issues or stop/start while burning should be entirely hidden and should never prevent writing to a disk which is not full, or cause the CD or DVD to behave as if it has multiple unrequested partitions.

 

Bug on list since: Jan 2005

 

Bug Name: What's this file for?

 

Reported by: Dan Wheeler

 

Duration: 1980

 

Supplier: Microsoft, Apple, possibly others

 

Alias: WTF (What's this file?)

 

Product: Operating system's interaction with files

 

Bug: Can't tell what a file is by it's contents

 

Class of Error: Lets encode intelligence into the file name, after all, the user does it

 

   Principle: The name of the file should be completely upto the    user.  The user should not have to remember what application is    required to read the contents of the file

 

Proposed Fix: Do it the UNIX way.  Lot of flat ASCII files should be used.  Binary files should use the first line to describe what application should be used to open it.

 

Bug first observed: (1980 -tog)

 

Bug reported to Supplier: That's funny.

 

Bug on list since: Jan 2005

 

Bug Name: Drafts are not automatically saved

 

Reported by: Nathan Eady

 

Duration: >20 years

 

Supplier: Microsoft, Apple, all known Unix vendors, ...

 

Alias: You Should Have Used "Save As"

 

Product: Virtually everything.

 

Bug: Once a document has been edited and saved, there's no easy way to recover earlier versions.

 

Class of Error: You wouldn't want to waste precious disk space!

 

    Principle: Basic prevention of data loss.

 

Proposed Fix (Applications): undo information should be saved alongside the document.  (For reasons of privacy with document exchange, it should probably not be embedded in the document, but saved in a separate file.)

 

Proposed Fix (Operating Systems):  ITS had file system versioning in the days of yore; VMS had it when the Vax was introduced, and OpenVMS/Alpha has it today.  We know it's possible to implement.  It's high time we get file system-level file versioning, at least optionally, in desktop operating systems.

 

Discussion: Obviously, some files should not be versioned.  Log files spring to mind, for example.  So a versioning file system would need to have a per-file or per-directory setting to turn it on or off in different places.  But above all, the users' home directories and everything in them should be versioned by default, and graphical file managers should understand the versioning mechanism and group multiple versions of a file, while still providing access to old versions.

 

Users now are buying computers with 60+ GB hard drives, many of which after five years of use will still have 55+ GB free.  There's more than enough room to store fifty revisions each of a typical user's 200-odd word processing documents at a few kilobytes per version.  The /etc hierarchy on Unix systems would also benefit greatly from versioning. If a user chooses to turn this feature off to save space, fine, but it should be provided by default.

 

Bug first observed: when dinosaurs roamed the earth

 

Bug on list since: Jan 2005

 

Bug Name: Inconsistent terminology

 

Separately Reported by: Ken Keefe and Phunky Monkey

 

Duration: >15

 

Supplier: All

 

Product: All

 

Bug: Terms used in UIs are inconsistent. For example: "Options", "Settings", and "Preferences" all usually mean the same thing. Why not standardize on one term?

 

Class of Error: Inconsistent Design

 

Principle 1: Use existing terminology for existing objects and functions

 

Principle 2: Common tasks should be located in standardized menus and menu items, so that the user does not have to scour an application's menus looking for a synonymic menu item.

 

Proposed Fix (K. Keefe): Form a standards organization like the W3C and others, to set standards for application designs across companies, operating systems, and architectures.

 

Discussion by K. Keefe: Ok, so maybe I am a web developer that believes very much in standardizing applications and content. Maybe I wouldn't mind having a bumper sticker on my car that says, "I, for one, welcome our new W3C overlords." However, it seems to me that graphical applications that subscribe to the menu driven approach (or even toolbars maybe) should have menus that are standardized.

 

That way, when a user wants to change the settings of a program, they can go to the generally agreed upon menu item instead of looking for File->Settings, then Edit->Preferences, then Edit->Options, then Window->Preferences, then Tools->Options, and so on. If nothing else, it would allow me to spend less time on the phone tech supporting family members and their applications because I'd know where each task is, regardless of their specific application.

 

This is already being done to some degree (File->Print, File->Exit, etc.) but it could easily be expanded to hold many, many more common tasks.

 

Discussion by P. Monkey: There's nothing I find more frustrating in teaching computing, than having to deal with inconsistent design. The menu items in two programs may use completely different paths and wordings to get to the same functionality. So, I constantly have to help people by telling them that sometimes the settings are in the file menu, or in the edit menu, or in the tools menu... and may be called "Options", or "Preferences".

 

   This actually applies on a much broader scale, than just word usage, but this specific instance has always been a pet peeve of mine.

 

Discussion by Tog:  This probably began with the Apple-Microsoft lawsuit that followed Microsoft’s wholesale piracy of the Apple GUI.  Apple began the suit attempting to declare copyright over every single detail of the interface, an attempt that failed long before the balance of the suit failed, but probably lasted long enough that the Microsoft lawyers in charge of Windows design instructed the team to purposely develop different terminology.

Whatever their reason, Microsoft made a clearly conscious effort to use different terminology for established objects and functionality, always, in that Microsoft way we’ve come to love, choosing a more “machiny” term than Apple’s humanistic original.

In case no one has noticed, Microsoft has won the war, against everyone.  Were it not that the net egos of Silicon Valley CEOs are actually 12.3% larger than Bill Gates’s net worth, Apple, Sun, and others would have conformed their placement and terminology to Microsoft’s long ago.  Instead, these guys continue to play into Microsoft’s hands by making the transition from Windows to Something Better as difficult and confusing as possible.

We have a de facto standard for placement and terminology.  It is as close as the nearest Windows computer.  I’d recommend the 79 pound gorillas use it, before the 500 pound gorilla kicks even more sand in their faces.

 

Bug on list since: Jan 2005

 

 

 

Bug Name: end-of-line confusion

 

Reported by: Anthony Wesley

 

Duration: Forever

 

Supplier: Everyone

 

Alias: Why the f**k didnt that file transfer properly?

 

Product: O/S specific: UNIX, Mac, Windows

 

Bug: Lines of text can be terminated with:

 

               a) CR  (Mac)

               b) NL   (Unix)

               c) CR+NL  (Windows)

 

depending on what OS you are using. This would be one of the most pervasive and stupid decisions in history. Look at how much effort in the industry is aimed at handling this one "feature".

 

With option (c) , thanks to CP/M and DOS et.al. , file sizes are no longer equal to the number of bytes that they contain under some circumstances.

 

Class of Error: shortsightedness rulez ^M^M^M

 

Principle: Don't Do Anything Stupid

 

Proposed Fix: Pick (a) or (b), ditch (c), and make EVERYONE switch under pain of DEATH.

 

Discussion: No discussion, just DO IT.

 

Bug first observed: 1986 (first year I used UNIX)

 

Bug reported to Supplier: Yeah, Right.

 

Bug on list since: Jan 2005

 

Bug Name: Scroll bar involuntary reset

 

Reported by: Joakim Rosqvist

 

Duration: > 10 years

 

Supplier: Most GUIs

 

Slogan: “Let’s start over from the top!”

 

Bug: Difficult to browse a document that does not fit on screen.

 

Principle: The users choice of viewing position should be respected.

 

Discussion: You open a document to look for some text and drag the scrollbar to move through the text (extra evil points if the text does not update until you release the scroll bar). Eventually, after a couple of minutes you find what you were looking for and start reading. Isn’t that window a little small? Let’s resize it. The windw is repainted. Centered around the cursor position. The cursor is still at line 1 col 1 since you have not used it yet. I hope you remember where that text was, Ôcause now you’ll have to find it again.

 

There are oh-so-many reasons for the program to reset the scroll position. Switching between read-only and read-write mode? Check. Some extra data was inserted into the document/table/whatever you are viewing: let’s repaint from line 1. For extra credit, combine with Windows’ tendency to undo your scrolling if you stray outside the allocated corridor of mouse movement when dragging the scrollbar (easy to do when you keep you mental focus on the text rather than the scrollbar).

 

Proposed Fix: Let the scrollbar move only when the user drags it.

 

Bug Name: No “No to All”

 

Reported by: MKruk

 

Duration: 20+

 

Supplier: Microsoft, others

 

Alias: No! No! No!

 

Product: Windows Explorer, other file managers, command line tools

 

Bug: When you copy 2000 files to a location which already contains 50 of them Windows Eplorer, et. al.,  will ask you whether you want to overwrite the destination file or not. It will give you an options to say “yes to all” but not “no to all”. As a result you either click no 50 times or copy 50 more files that you need.

 

Class of Error: “We got it almost right, why bother getting exactly right?”

 

Principle: Anything worth doing is worth doing right

 

Proposed Fix from Tog: When you’ve recognized a problem, fix it!  Don’t just take a stab at it and decide it’s good enough.  It isn’t.

 

Discussion: This bug cost humanity millions of dollars in hard drive wear and tear over the last 10 or 20 years.

 

Discussion by Tog: It’s cost more than that in lost human productivity and mental heath.  It’s a particularly nasty trick because it is perfectly evident the designers recognized the problem, but chose to do just enough about it that the ignorant would assume they’d done all they could.

 

OS-X is still doing this one wrong, but not nearly as wrong as what’s come before.  It’s a start, and I hope they’ll go on to fix it, so MS will have something better to copy.

 

Bug first observed: 1980

 

Bug on list since: Jan 2005

 

Bug Name: Long boot times

 

Duration: [in years]

 

Supplier:  apple Microsoft, et. al.

 

Alias: Start up computer, go get coffee.

 

Product: all computers (and spreading into other thigs, like my phone)

 

Bug: When I boot up my machine I have to wait for it to go through all sorts of internal machinations before I can do any thing.

 

Class of Error: Why should I wait?

 

Principle: The user’s time is more important than the computer’s.

 

Proposed Fixes: 

 

1. Universal Hibernation modes
2. Reliable Sleep modes
3. More efficient boot code

 

Discussion: Despite my current computer being about a 100 times faster than my first one I still have to wait as long for it to boot now as I did 15 years ago. While a computer is a complex machine, other complex machines can manage much more immediate response. For example, an automobile. While a cold car engine needs to warm up to an optimal temperature for maximum efficiency and fuel economy, it will still drive while warming up. In fact, I don’t even know how long it takes to warm up, because I get to immediately start on my task of getting somewhere.

 

The palm managed to implement an almost instantaneous start up time, however things seem to be sliding backwards. My most recent phone now requires a ridiculous amount of time to start up as does my dvd player. Granted both of these play me a cute little animation and a song, but why not spend time making it start faster rather than figuring out how to play a jingle.

 

As someone who carries a laptop between home, work, and all too many meetings everyday, sleep mode is a godsend. (Although, of course it still makes me wait.) However I still need to reboot or shutdown every so often be it for saving the battery, installing software, crashing, or just trying to fix some sort of system sluggishness. Then, despite all the speed of my brand new, top of the line machine, I have to wait just like when I booted from a floppy.

 

Discussion by Tog:  My current computer is a thousand times faster, and the boot process is, conservatively, 100 times slower. My original Apple II was almost instant-on.  Companies are doing a really poor job in this area, presumably with the assumption that people almost never have to reboot anymore with today’s memory-protected OSs.   That would be true if every-other update didn’t demand a restart, with the OS suppliers the most likely to do so.  OS suppliers: you are not making people happy out here!

 

Apple, in particular, needs to supply a hibernation capability like Microsoft’s.  It gives Windows a real competitive advantage.

 

Bug first observed: When was the first crash?

 

Reported by: Aaron Spaulding

 

Bug on list since: Jan 2005 

 

Bug Name: Install restart

 

Reported by: Dave Dorr

 

Duration: 10?

 

Alias: “Viruses can hijack your registry on the fly, but real programs can’t get in!”

“Please wait while your system is updated...”

 

Bug: Installing a new program (not related to the OS) requires a restart.

 

Class of Error: “You are not in charge; we are”

 

Principle: Installation of new programs can only be recognized when the initial Ôscript’ for the OS is run, so a restart is almost always necessary.

 

Proposed Fix: Allow more flexibility with installs (already happening to some degree) so restart only occurs with a major system update.

 

Discussion: Good OSs have done this for years, and it is unclear to me why this is required in Windows.

 

Discussion by Tog:  Mac is just as guilty, if not more so. Even routine minor update installs under OS-X often demand an immediate restart, though none is needed until the user chooses to have the new functionality.  The only way to kill the restart is to kill the process demanding the restart, after which, users can continue their work in the normal fashion. As long as you’re a systems engineer, this procedure is obvious.

The promise of the fancy new operating systems was that constant restarting would be a thing of the past.  That promise is being broken, often on a daily basis.

 

Bug on list since: Jan 2005

 

Bug Name: Visible File Extensions

Reported by:

 

Alias: File Extension Bingo.bak

 

Duration: From the beginnings of DOS, perhaps before

 

Supplier: MS, *NIX’s

 

Alias: guess what this file does?

 

Product: Operating Systems

 

Bug: Usually-arcane three-letter extensions are used to associate files with applications. Users must learn that “.doc” is opened with a particular word processor, yet “.wri” is handled by a different one. Worse, after forcing users to learn this, OS manufacturers frequently attempt to hide the extensions.

 

Class of Error: Model-T

 

Principle:  When (and only when) complexity can be safely hidden from the user, it should be

 

Fix: Files should be associated with an application via meta-information stored in the file. Any application attempting to open the file could read the meta-tag, and inform the user that:

 

a)      This file is not readable by this application, and

b)      The file may be opened by this (other) application, and further

c)      It could even launch the application for the user.

 

For example: Selecting a file to be opened, opens the appropriate program. If no

application is associated with the meta-tag, then the OS informs the user that this

application is registered to be used by a specific application or is part of the operating system.

If the user attempts to open a file created by a spreadsheet program with a word-processor. The word processor reports that the file needs to be opened with a spreadsheet program, and would they like to open it?

 

Discussion: Though moving in the direction of a solution, we’re still married to the idea of file extensions.

 

Discussion by Tog: The Macintosh kept meta-information hidden from its users from the inception of the interface.  Windows could have provided a smooth transition from DOS by optionally hiding the file info, using the Apple scheme (they copied everything else), but chose not to.  The result has been unnecessary complexity in the Windows world for the last fifteen years.

 

OS-X introduced this Windows scheme into the Mac world, neatly integrating it with its own historical presentation.  At the same time, it made it easier for users to redefine the “attached” application.  Apple was correct in incorporating this “downgrade,” making life much easier for its many users forced to use the other leading brand at work. Microsoft, with its stranglehold, is the only party that can change the status quo without causing injury and confusion.  As long as it clings to the 1970s, this bug will continue to crawl about.

 

Bug on list since: Jan 2005 

 

Bug Name: Close Window vs Close Application

 

Reported by: Lee Read

 

Duration: eons

 

Supplier: Windows, Unix, etc. (not Mac)

 

User response: “What the? Oh crap!”

 

Products: Apps, OSs

 

Bug: The close window icon is not sufficiently visually different from the close application icon.

 

Class of Error:

 

 Principle: Shortcuts should save time, not cause errors

 

Proposed Fix: Remove unnecessary shortcut for close-app from window border

 

Discussion: For example, in Windows it is a graphical little x. To make matters worse these little icons are physically smack dab next to each other.  I don’t know how many times I’ve accidentally closed an application when all I really wanted to do was close a window within an application.

 

Discussion by Tog: Many long-time non-technical users of Windows have no concept of the difference between closing a window and exiting an application.  It would appear that more than a few Windows applications share the same confusion.  With a modern operating system, little reason exists to constantly be exiting and rebooting applications.  Applications should be exited from the File menu or by use of a standard shortcut key.

 

Bug reported to Supplier: 2004-11-29

 

Bug on list since: Jan 2005

 

Bug Name: Dude Where’s my File

 

Duration: Since UNIX was created

 

Recognized for what it was: 1997 when BeOS showed adequate solution

 

Supplier: Microsoft, FSF

 

Product: Windows, Linux, BSD, others

 

Bug:  Navigating up the directory tree in Windows from a folder on the Desktop takes you up as far as the “Desktop” but no further—not up to your user directory, just up to the Desktop. UNIX scabs file systems onto wonderfully mysterious places like /mnt / /usr /var /home, leaving me to wonder how do I put my presentation onto my thumb drive again?Apple’s Finder pretends that /Volumes is the start of the file system and then adds Network into it

 

Class of Error: 

 

Principle (from Tog): When new or expanded capabilities are added, enlarge or replace the conceptual model, so a new, smooth, more encompassing model results. Do not just slap additional models on the side, eventually resulting in a giant, misshapen potato (to use a metaphor).

 

Proposed Fix: It is one thing to copy Apple when they’ve done it right.  It’s quite another to copy their mistakes. “Be” solved the problem.  Copy them.

 

Discussion: People have been messing around with the File heirarchy since the dawn of file systems. “Be” got it right; Apple only almost got it right. Microsoft, if you are going to copy something, copy it don’t pussy-foot around almost copying it to avoid the impression of copying, and UNIX zealots, get your heads out of your asses and drop the legacy crap: Go copy the system files in [Startup Disk]/System everyone else uses. Disks are bigger than 32 meg these days.

 

Discussion by Tog:  The network and everything on it are dangerously mysterious to most people, largely because the conceptual model they’ve learned to use for their personal system is swept aside when they go higher in the network hierarchy, replaced by a model that is dangerous and mysterious.  GUI-based personal computers have been attached to networks since the early 1980s.  It’s time the interface caught up.

 

Bug first observed: 1996 went to college and used Solaris/Digital Unix for the first time, 1997 when used Be for the first time and again summer 2001 when I had to get a “real” job with an employer suspicious of Mac’s

 

Reported by: T.K.Egan

 

Bug reported to Supplier: summer 2001

 

 

Bug Name: Primitive File System model

 

Reported by: Jason Hiltz-Laforge

 

Duration: Since late 1970s

 

Supplier: IBM, MS, Apple, Sun, HP, et. al.

 

Alias: File it under “Stupid”!

 

Impressed user who has been living under a rock: “Electric Filing Cabinets!! Well, now I’ve seen everything!”

 

Product: OS

 

Bug: Information is structured like an endless filing cabinet—directories and files.  The physical model for storage when computers were invented is simply reproduced by OS file systems.

 

Class of Error: Frozen in time

 

    Principle: When you have a thousand-fold increase in the average number of documents, you should strongly reconsider your conceptual model

 

Proposed Fix: Model View Controller architecture for file systems—if it’s efficient for the computer to store it this way, fine.  But let users present it in a way that suits their needs.  Wouldn’t it be great if I automagically had a folder named Music, and in it I could browse by artist, or music type, or date of release or album name, or...?

 

Discussion:

 

iTunes’ feature that lets it organize music files is a great example of the type of thing that should just happen automagically in the OS.  Applications should not have to get around the physical model imposed by the OS — they should be given a choice as to which logical model they’d like to expose.

 

The organizational model imposed by the OS violates the way people think about their files, and that’s the main problem.  My parents have no idea how to fire up Windows Explorer.  Heck, most of the time, they don’t know where they saved something from one day to the next.  But, when they sit down at the computer, they do know that they want to finish writing the letter they started yesterday.  So, present the information in a logical manner: allow users to view objects by intent (letter) and date (yesterday), instead of by “extension” and “path”.  They don’t know a .doc from a .exe — don’t make them learn what is an utterly useless chunk of knowledge to them.  If the computer needs to know, fine.  If a power user needs to know, let him do some work to get at it. MOST people don’t care — so don’t show them.

 

Discussion by Tog:  In my 1996 book, Tog on Software Design, I presented in detail just such a conceptual model, one that also extended out to include objects that actually (gasp!) didn’t even look like folders!  I considered it around 10 years overdue at that time. 

 

Interfaces remained frozen in time from January 24^th, 1984 until the release of OS-X 10.3.  During that period, Apple either considered the job done or was struggling to adapt the old interface to a new underlying architecture.  Microsoft, meanwhile, was floundering around, trying to make its own copy of Apple’s 1984 interface. 

 

With 10.3 and the release of Expose, Apple is finally on the move.  Microsoft, meanwhile, has completed its copy and has begun to actually innovate.  Perhaps, by 2006, we may have the interface we deserved twenty years previously.

 

Bug on list since: Jan 2005

 

Bug Name: Unexpected Disk Full Error

 

Reported by: jonesey

 

Duration: 20+ years

 

Slogan: “We couldn’t possibly check for a full hard drive! You figure it out!”

 

Product: All devices with hard drives

 

Bug: Operating systems and software applications very often do not check to see if they have enough room to create files on hard drives.

 

Class of Error: Lazy programmers everywhere.

 

Principle: The user should not have to do work that the programmer should have done.

 

Discussion: Applications and operating systems frequently return bizarre and misleading error messages when disks or partitions become full. In most cases, it is clear that there is simply no code written into the application in anticipation of disks becoming full; applications expect infinitely large disks, not one of which has ever been observed in the wild.

 

Proposed Fix: Operating systems should check for full or nearly-full disks and return sensible error messages to applications and to users. Applications creating temporary files on disks or partitions that are nearly full could look for other disks or partitions to use automatically.

 

Bug first observed: A long time ago.

 

Bug on list since: Jan 2005  

 

Windowing

Bug Name: Window can’t be resized

 

Reported by: Jeff Wolverton, annonymous

 

Duration: since 1980

 

Supplier: All GUI OSs

 

Product: Many

 

Bug: Window is too small, but developer has “turned off” resizing option

 

Principle: The user is in charge

 

Proposed Fix: Change OS toolkits to make all windows resizable

 

Discussion by Jeff: All windows should be resizable. ALWAYS. Why “prevent” the user from resizing a window (AOL and Windows still sometimes do this for windows with LISTS, for heaven’s sake. As if someone decided we never need to see more than seven of the 109 things we’re scrolling through.) Never forbid me from resizing my own windows; I paid for this.

 

Discussion by Tog: There used to be a way on the Mac to override the wishes of incompetent designers who had turned off sizing of windows.  Mac users could hold the Option key while grabbing the lower-right corner of the window and grow it, regardless of setting.  Those were good years.

Even though, in many cases, users have no need to resize windows, I’ve never seen a case where damage would occur should they do so.  On the other hand, I’ve seen case after case where the designer’s choice to turn off resizing has severely damaged productivity.  OS people, it’s time to take the power to make the users’ lives miserable away from incompetent designers.  Give users a way to override their decision or remove completely the ability to turn off resizing.

 

Discussion by Anonymous re: one particular supplier: Micro$oft..., follow your own UI guidelines! [The problem is] you don’t give a rat's rootie-patootie.

 

Bug on list since: Jan 2005

 

Bug Name: Window controls too tightly clustered

 

Reported by: dapalmer

 

Duration: since 1981

 

Class of Error: Ignorance

 

Principle: Fitt’s Law

 

Proposed Fix: Spread window controls out (dapalmer), and place close box in opposite corner (Tog)

 

Discussion: A favorite lunacy in design for me is to group the window control buttons  (expand, full-screen or kill) tightly up in the top right corner.  This means that you always have to execute extremely tight dexterity to hit just the button you want.  About 5% of the time, you miss and do the opposite of what you want.  An ergonomically friendly approach would be to put the buttons on opposite corners.

 

Discussion by Tog: Fitts’s Law dictates that the further an object is from you and the smaller it is, the longer it will take to acquire. (Duh!)  Apparently, few associated with either Windows or OS-X has apparently ever heard of this law, because they routinely step all over it. The window controls are but one example.

 

I advocate placing the close box in the opposite corner, not only because it provides greater separation from options that result in less lost time from errors, but because it requires an entirely different “gesture” on the part of the user, resulting in fewer errors to begin with by virtue of motor memory.  It worked pretty well at Apple for 20 years, until the OS-X crowd felt the need to fix it.  If you attempt to fix something that isn’t broken, it will be.

 

Bug on list since: Jan 2005

 

Bug Name: Active window hides everything else.

 

Reported by: Rafo

 

Duration: since the very first superimposable windows GUI system.[That would be the 1981 Apple Lisa—Tog]

 

Product: every OS except AmigaOS/MorphOS (and maybe a few windows managers, I’m not sure about that, I’m not a unix/linux/X11 addict).

 

Class of Error: To see a part of a window, you are forced to see all the window.

 

Principle: when you activate a window, it always becomes frontmost, hiding every other window.

 

Proposed Fix: use an Intuitable. library-like system. (check the Amiga Workbench).

 

Discussion: Imagine you have your IRC window covering almost all the screen, then watch a video, on watch what’s goin’ on on in Messenger. The Messenger window is ABOVE the IRC Window while you’re IM-ing. But then, you need to write something in the IRC Window. Why does the IRC window have to come frontmost, as long as the IM window doesn’t annoy you ? On AmigaOS, windows have a “depth gadget” which can be used to switch a window back or front. But the most used setting is to double-click a window to make it frontmost. Just one clik activates it and you realize that most times you don’t need to see the WHOLE window to know what you are doing and it saves many clicks when you come back to what you were previously doing (I don’t know if I’m correctly understood). Ask any Amiga user to make you a short demo you’ll understand very quickly the purpose of this feature.

 

Another example: you are coding with VisualStudio (or any other IDE). This window has to be full-screen if you want a comfortable display. But you also have to consult a datasheet PDF you need for your code. OK then you have your Acrobat Reader window, quite small in the right of the screen, for example. And when you want to type something in your code, you activate the Studios window and Woof ! the PDF window disappears. You have to switch windows to have you PDF window visible again. Do it a hundred times and you’ll understand what I mean when I say the VStudio window should stay just whether it is so that it’s still displaying when you type your code. If you have 2 displays, it’s ok, but if you don’t, it’s a complete nightmare.

 

Discussion by Tog:  These kinds of useful features lie buried in a wide range of obscure OSs and applications.  Sun’s Solaris featured a push-pin icon in windows that would normally close when you were through with them.  Pushing in the pin would hold them open.  Often, you’d want the window to close.  It may have popped open to enable you to changes some parameter, for example, on a file.  But on those occasions when you might want to change the parameters on a whole bunch of files, pushing in the pin would make life much easier.

 

In other OSs, developers are expected to decide, window by window, whether they remain open forever, or slam shut regardless of the user’s wishes.  Good idea, also not well known.

 

Bug on the list since:  Jan 2005