On 2/27/06, Tristan Wibberley <<a href="mailto:maihem@maihem.org">maihem@maihem.org</a>> wrote:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, Now that my trollish subject has got your attention :) I've watched my father on his Windows XP machine trying to grapple with the switch user concept. When finishing with the machine at a time when somebody else wants to use the computer, he will want to press switch user every time, no matter how much I explain the general rule "If you've finished with the computer use log off, only use switch user if you expect to go back on shortly". I wonder if something other than "Switch User" should be used. I also think he gets confused with clicking log off only to be offered something else instead - he might be trying to select the other option because he reckons the computer thinks he may be choosing the wrong thing.</blockquote><div> Good point. There are cases when switch user makes sense, and there are cases when logoff makes sense. I guess most people, given the option, would always choose "switch user". We tend to think, "I may want to resume working, so let's keep it ready". Logoff implicitly means "restart", in the sense that the user will get a new session when loggin in later. So in this sense, "switch user" is the best option (at least, it is what people want most of the time). Now, if you forgive me, a short rant... The issue here is persistency. Current desktop systems are not really designed to support persistent sessions. I guess this is more a consequence of historical technical limitations than a well thought decision. Regardless of reason, we still do not know which is the correct model to apply to the design of a persistent system. Let's assume a perfect world, one where hibernation really works, 100% of the time, and where RAM usage is not an issue. Sessions could then be made persistent by default, and it would be much more convenient to suspend and resume sessions instead of loggin on & off. I guess this is more intuitive -- if you leave the computer, you could always resume working where you left. Of course, things are not that easy because there's the issue of sharing (and locking) resources such as files. In a fully persistent system a user could (potentially) leave resources locked in such a way that no other user could actually use. Going further, I'm really not sure what's the correct behavior in a persistent system; do you keep files locked for the user that is editing them, or do you allow other users to edit it? What do you do when a user resumes working with a file that was modified by someone else? It's about the same as leaving you office and finding next morning that someone wrote over the sheets of paper that you left over your desk the previous day. In the real world this is not a big issue for purely physical reasons -- most people do not mess with a coworker's desk, and if they do it, they will usually leave a message telling what they did. Even if they do not leave a message, most people would promply realize that someone messed their desktops. A virtual environment is not well suited to this model. Implementing seamless persistency poses interesting questions. It goes beyond our physical experience, in the sense that objects can be shared or locked in ways a physical object can't. In this sense, things like a wiki seem to point to another way of doing things, with finer grained control over resources and a fairly volatile concept of 'locking'. Now that technical limitations against persistency are finally being overcomed, it will still take a lot of time to get the model right in usability terms. </div></div>-- Carlos Ribeiro Consultoria em Projetos blog: <a href="http://rascunhosrotos.blogspot.com">http://rascunhosrotos.blogspot.com</a> blog: <a href="http://pythonnotes.blogspot.com">http://pythonnotes.blogspot.com </a> mail: <a href="mailto:carribeiro@gmail.com">carribeiro@gmail.com</a> mail: <a href="mailto:carribeiro@yahoo.com">carribeiro@yahoo.com</a>