iPod Touch: Improvement Ideas

I love the iPod Touch and it's quickly become my favorite little mobile electronic gadget. Very useful. Very fun. Very cool looking. Sleek. Addicting. Lots of smart choices and design decisions went into it. Apple rocks once again.

But it ain't perfect. At least for me. So I'm documenting here a list of problems I've had, or ideas on how to improve it.

I have an iPod Touch 16GB model with the 1.1.3 firmware and the January 2008 Software Upgrade.

Safari

1. a way to click on a link such that it opens in a new, separate tab/window from the current one. This ability is one of the killer features of modern desktop browsers such as Firefox. Actually it's what I do on both Firefox and Safari, on both my PC and my Mac: I frequently scan through a blog-type web page and click on any link that interests me in such a way that it opens each in a new separate tab, without grabbing focus (they begin fetching into a background tab) and I continue reading the original page. Only once I'm done digesting the original page do I want to go look at the other newly opened tabs. Since the fetching for them occurred in the bg, I often don't have to wait once I switch to their tabs/windows: the page has finished loading and rendering so I can begin reading them immediately. This is a time saver and huge convenience and user experience win.
2. hitting the Back arrow should not re-issue the prev request (a refresh) but rather just switch back to the rendering of the prev state. Currently you are forced to wait for a new req/response round trip to finish before you can see/use the prev page. This is unnecessary and annoying. It seems more smart to me that if a user truly wants to refresh/re-issue a page request that he simply hits the Refresh button. This would be more orthogonal and intuitive behavior, and more consistent with how browsers on desktop computers work. It could reduce battery power drain by reducing WiFi antennae use, and bandwidth/traffic on your provider, although in exchange for more memory use on your iPod Touch. ALSO once it has returned to the prev page's view, it should also be focused on the same spot as before. In terms of (x,y) focus and zoom level.
3. issue #2 compounds the problem caused by issue #1, and vice versa
4. double-tapping sometimes does not zoom in as I expected. Instead it seems to bounce or reject my zoom request. I'm then forced to do the two-finger-spread-out-motion technique, at the same spot, to make it zoom in. Not a huge issue, but a minor annoyance as it would be easier and faster to do the quick double-tap. The two-finger-spread makes more sense if I want to control precisely how much zoom in/out occurs. If I don't care, i just want it bigger/closer, the double-tap would suffice. Overall the link/button tapping, and page zooming & panning features of the browser UI work great, and are a joy to use. This is perhaps the only minor issue I can think of offhand.
5. fix the crash bug(s). Safari crashes "to desktop" about once a day or so during use. At least the core GUI/OS stays up and I can usually get back to where I was before, but it's annoying and unnecessary that I take that time and focus hit.

Music

1. smart sound volume limiting. The problem right now is that I frequently have to fiddle with the sound volume when a new song starts playing, because the played volume is either painfully too loud or far too quiet. I've turned on the Volume Limit feature, and tried setting that bar at different levels. No matter what I set it too, it seems to mess up the volume due to the logic it's applying. I've also played with the EQ and selected Loudness as the EQ profile. I did not notice any change nor do I know what the heck that does. I may not have done enough research into this issue so if this problem has an existing solution somebody please let me know. I don't remember having this much trouble with music volume on my classic iPod (5th gen? 30gb, black, video). The rule I want the player to follow is something like, "By default, play the song at the default volume specified in the sound file. UNLESS the maximum volume the player would emit would exceed some arbitrary volume level limit in the user options, in which case, the max volume played should be precisely that limit level, and the rest of the sound's within that file should be automatically adjusted downward in volume by a proportional amount, ideally without distortion (but meeting this goal is not as important as the requirement to cap max volume.) ALSO if the highest volume sound within a file is too low (too quiet) then dynamically adjust upward the volume of the entire sound file, maintaining proportions where possible, such that the highest volume sound is no less than some minimum level specified in the user options. Both the hard minimum and hard maximum volume limits are specifiable in the device Settings. The user can hear a sample tone played in his ear played at the current volume level he's considering, so he can get a sense of how loud or quiet that level is. I don't see any reason why, via hardware and/or software, this behavior can't be enforced. Maybe it's possible and I just haven't RTFM enough yet. Maybe it's a planned future upgrade.

YouTube

1. specify an existing account on YouTube to use, so that Favorites and Subscriptions are the same or synchable.
2. way for user to manually re-order Favorites, similar to how he can do Safari Bookmarks (unless app is associated with a YT.com account, in which case, use the same order as used there.)
3. smart sound volume limiting (just as I'd like to have in the Music app)

Notes

1. a way to sync content with your desktop computer. Notes is a great tool when I'm out and about to take and see notes. I mostly use it for TODO lists, but sometimes also for recording brainstorms or design ideas. But then the content becomes somewhat "dead" because I can't easily access it from my desktop computer. The email option does not cut it, because it sends a one-way snapshot to the dest address. The data on the far side (the received email) cannot be modified there unless you're willing to create a fork, or lose all new changes (they won't propagate back to your iPod Touch, thereby getting out of sync with the version there.)

Weather

1. 'update failed' should not cause the previous weather report to be blanked out

Stocks

1. graph time-period logic/plotting done by a crack monkey. it literally hurt my brain trying to reconcile the number differences implied between the various period sizes, I saw so many contradictions and non-correlations. Things that should have overlapped didn't. Things that did overlap would report different values for the same time slice. Maybe your app isn't at fault and it's just blindly rendering the data it gets from the source feed. In which case, the data feeds are provided by a crack monkey.

Google Maps

1. way within Google Maps to make it show the location (Pin?) of every contact in your Contacts data that has an address. Since a contact can have an address and Google Maps can show addresses it makes sense that there should be lots of useful 'two-way' connections between these two apps.  What's good already? The fact that starting in a Contact I can click on an address and it takes me into Google Maps focused on that address. That's useful. It would also be useful if I can start with a particular location/address and then make it show (on map, perhaps via pins) or list (in some scrollable report?) all contacts whose address is within X range, for example. This entry is more of a thinking-aloud, nice-to-have entry, and not describing any serious problem or bug I'm experiencing, so no big deal to me if nothing like this ever gets added. Things like the non-cache-using Back button in Safari, or the auto-psychotic-text-clobbering feature of the Keyboard are much bigger issues.

Flash

1. add it! it's missing. and yet it's almost everywhere on the web, used in different roles. I understand what some of your reasons may be for not supporting it (1: to be anti-Adobe, 2: to encourage non-"proprietary" alternatives, 3: to encourage a proprietary Apple alternative, 4: preserve CPU, 5: preserve battery, .... other reasons?) but my web experience is worsened on a daily basis by not having Flash work on your device. You would get me to spend more of my web use time on iPod Touch rather than my desktop computer if you supported it. On a little more personal note (although on one that I'm sure lots of other people share) I have a business that provides Flash-based web applications. It sure would be nice if my customers and also myself as the developer could access these Flash apps on your device. Would increase my market, and increase the usefulness of your device to those folks. Seems like almost everybody would win. Again, unless somehow one or more of the 5 example concerns I cited above are weighted more heavily in your decision-making.

Keyboard

1. option to turn off the autofix/suggestions functionality. In many cases it's annoying and imposes makework on me, imposing a sort of "Microsoft Knows Best" anti-pattern of UI behavior. I often type using personal slang, industry-specific terminology or lingo, acronyms and abbreviations (to save typing) and I am frequently bitten by this autofix/suggest thing clobbering my input, changing it to something else, or otherwise requiring me to perform an additional input task (moving my finger from its original position over the keyboard up to the text body and tapping to dismiss their suggestion, then moving back to the keyboard again), thus unnecessarily slowing me down and annoying me. Fixing what is obviously or very likely a spelling error ('jsut' should be 'just' 99%+ of the time) is a good thing. Clobbering or distorting an acronym ('amd' becoming 'and') is bad. Especially in the Notes app where it's perfectly acceptable if my saved note contains spelling errors, because I will still know what it means. If I could turn off this feature in Notes, and thus increase the number of spelling errors saved in my notes, but also experience less clobbering/distorting of what I really did intend to type, then I would be happy with that tradeoff. If in my save notes the app has clobbered or twisted my input into something that I cannot "work back" or deduce what I intended to say, that is the fault of your software, not me. The autofix/suggest functionality may be a net-win in certain apps/contexts (web browsing & form input, contacts, calendar) but a net-loss in others, like Notes. And I'm sure it would vary by person. A perfectionist with great spelling who uses lots of lingo and abbreviations may hate this feature, whereas the opposite type of person may love it. Make it an option and let the user decide. Easy win!

General

1. ability to sync readable documents (such as PDF and TXT) from my desktop and read them on my iPod Touch anytime at will, even offline. Basically do for them what the device already allows for images and video. I'd love to be able to have fiction and non-fiction books, as well as reference manuals or guides, on my iPod wherever I go. I could read a book or consult a manual whenever I needed or had the time.
2. Image sync fails on common formats and fails mysteriously. When i sync images some of the images on my desktop computer consistently fail to do so, for no given reason. I just get a popup error message telling me one of the filenames that failed. (A JPEG file, in my case.) I wish it provided more detailed information on exactly what files failed to sync, exactly why they failed. Or, simply, it should "just work". If the reason is simply that the files are an an unrecognized or unsupported encoding, then just tell me that, with details, so I can try to rectify the situation by converting them on my own. I have a sneaking suspicion that I haven't dug into this issue enough yet, however, and so it may be my fault for not doing enough RTFM. But it is one of the issues biting me, so I thought I'd list it for sake of completeness.
   
3. Copy-and-paste text between apps. So I can select a chunk of text on a web page, then switch over to the Notes app and paste that text into a notes document. Or into an entry in Contacts, or Calendar. Etc. I realize the trick is dealing with modality and input commands but there's probably a way to make it work. The 'move cursor with finger' functionality you provide in forms works pretty darn well, so perhaps the implementation could work like that when selecting text.
4. Web page WiFi portals are too manual and crack-addled. Using AT&T WiFi account access to the Internet (the kind where you request anything in a browser, it redirects you to a web login page, you submit your WiFi login credentials, now you're approved, and after that all your web & internet access requests work) has two pain points or opportunities for improvement. Would be nice to have some way where I could store (or it could remember) my login credentials on the iPod, so I don't have to manually type it in and submit a web form every time. And two, I notice that sometimes, when I am already logged in and accessing the Internet successfully, surfing the web, etc, and then I temporarily turn off my iPod (a soft off, not a hard off), to visit the bathroom, for example, and then come back out, sit down and turn it back on again, then try to access the internet, I find that it has de-authenticated me or otherwise forgot that I had an authenticated session, and redirects me to the login page and asks me to login again. This is just stupid. They should be able to use cookies and timeout functionality to ensure that I continue to be authenticated and allowed up to X minutes since I last logged-in and/or issued a request on their network. Simply putting my iPod to sleep for a minute or two should not cause it to throw away my status. It feels almost as if some hard signal or explicit behavior was coded to make it do this. It's bad for users, so don't do it. If the justification was, "Well, since you turned off the device, then turned back on again, the device doesn't know who the human is using it, it may be a different person than the one who originally typed in the login credentials." then that argument is bunk because that argument didn't prevent the Mail app from having a totally automated and trusting auth process. Plus, worst case, you could make the iPod, at the device level, require the user to re-login to the device itself, as whole, if you were concerned about that. But even that should be a user option. If there's some subtle underlying technical reason why my device must lose it's auth status with respect to my WiFi provider then at least give me a way to automate the submission of my login credentials. I realize that part of the issue is the fact that it's a web-based auth system. But I'm pretty sure that's not a showstopper constraint. It's just software. There IS a way to make it work. A thumbnail solution is to automate that form submit, that's a simple HTTP request to a particular address (which could be communicated to it from the Wifi provider, or grabbed from user settings), using a username/password, also stored in the iPod's user settings. Not hard to do.

Forkers

A forker is someone who unnecessarily forks a conversation or otherwise throws a kind of fork in the road. Forking is annoying and wasteful because it causes makework to be performed and imposes an additional burden of energy expenditure and brain gymnastics upon the victim of the forking. And it wastes time as well. Here's an example of a conversation in which a smart person named Joe encounters a forker named Bob. Put your self in Joe's shoes as you read it, and I think you'll understand.

Joe: I'd like a cheeseburger to go, and that's it. Nothing else.
Bob: Ok. Would you like fries with that?
Joe: No. Just a cheeseburger.
Bob: Do you want onions on the cheeseburger?
Joe. I don't know. I don't care about onions either way. Whatever it is by default.
Bob: Ok. But onions will cost you extra. They're not on the burger by default. So are you really sure you want onions on it?
Joe: I never said to put onions on it. I said I didn't care. Just do whatever it is by default.
Bob: Onions it is. Will there be anything else?
Joe: I said that in the very first statement I made to you. It hasn't changed since.
Bob: Sheesh! Sorry for asking. Don't be so prickly......Oh, and will that be for here or to go?
Joe: Nevermind. Cancel it. I'm leaving. *walks off*
Bob: (to himself) What a crazy customer.

That's an example of a bit of an extreme case but I think it illustrates the idea. Poor Joe has a brain and clearly said what he wanted at the very beginning, and idiot Bob, for whatever reason, kept unnecessarily forking and extending the conversation much longer than needed, wasting both of their time.

As a counter-example, let me replay the encounter above but this time replace Bob with a smarter, non-forking colleague.

Joe: I'd like a cheeseburger to go, and that's it. Nothing else.
Steve: One cheeseburger to go, that's it. The total is $1.57.
Joe hands him the money.

Do you see how much smarter and more efficient that was, for everybody involved? Joe wins. Steve wins. The burger restaurant wins. The economy wins. Civilization wins. Both Joe and Steve have more time and energy to deal with other things in life, and are also less stressed after the encounter. And I believe by engaging in an intelligent, efficient exchange it reinforces in both their brains the execution of that behavior and so it's more likely to happen in the future, as well. An ideal situation. The key difference is that a forker was replaced with a non-forker. To be fair, I don't know for sure that Bob was an idiot, it may just have been that he had some inane company rules or "customer interface script" he was required to follow, and that was the cause of his seemingly inane questions and cluelessness. Or perhaps the background noise level was too loud and he didn't hear Joe's statement. (But if that was true, Bob should have immediately told Joe, and Joe could have repeated it once, and no subsequent forking would have been justified.) If so, that sucks for him. But regardless, it was forking, and it's bad, and makes the world a worse place, so he should have not done it. I wanted to specifically point this out because this article isn't about saying "dumb is bad", which is rather obvious, but that forking is bad. And forking might be caused by seemingly smart (or at least, non-idiotic) people and processes.

Here's an example of forking that didn't involve a Bob-type person.

Joe is driving along a road one day.
Up ahead he sees that the road he's on forks into two distinct paths, one to the left and one to the right, though they both continue heading generally in the same direction as before (north, in this case). He's forced to choose which path to take, so as not to run off the road entirely. He quickly chooses the right path. (Ha.) As he drives along the right path, he glances off to his left to try to see exactly what it was that necessitated having the fork in the road. He sees no reason for it. There's just a path of empty ground in between the two forked routes. Eventually, both forked routes converge back together again.

Why would every driver be forced to choose which fork to take in the above example? What purpose did it serve? There didn't seem to be any. All the "designers" of that road have caused is a lot more time/energy/thought to be spent by drivers (maybe only a little per driver, but multiply it by millions of drivers on that road segment each year!), and probably have also introduced a new source of accidents that would not have existed otherwise. Therefore, this fork is stupid.

Forking can happen in everyday, casual conversation between people as well. It's not limited to situations where one person is a prisoner of some business process or rulebook. That said, there are probably exceptional cases where forking is not entirely bad. Where forking may have a beneficial side effect which offsets it's inherent negative aspect. For example, imagine a hostage situation where a police negotiator is talking to a kidnapper and wants to stretch out the conversation as long as possible, to help keep the kidnapper cool, thinking, and somewhat under control, possibly while a SWAT team moves in behind the building to launch a surprise assault. In that case, it would be smart for the negotiator to fork as much as possible, to draw out the conversation. The good outweighs the bad. But this is an exceptional case, not the norm. As a rule, don't do it.

Don't be a forker.

The Principle of Normal Use

I've developed an idea over the years that I call The Principle of Normal Use, or, PONU for short. It's an idea I use in evaluating the quality or appropriateness of the design of something. Particularly of things you come into contact every day like furniture, appliances, tools, containers, doors, architecture, and vehicles.

The principle is that a thing should work well in normal use by a normal reasonable person. To work well it means that it shouldn't do things like leak on the floor, cut you, hit you, be too heavy or too difficult to grasp, neither too low (close to the ground/floor) or too high (out of reach by a person of average height and arm length), too hot or too cold, should have reasonable default states or forms, and so on. The list of qualities it should have is fairly long and depends on the exact thing in question. A door has certain ideal qualities that are irrelevant or don't make sense for a hand tool, and vice versa. It takes experience and a little insight to learn what works and what doesn't, what is smart and what is dumb with respect to any given category of thing, but when a thing violates PONU you will know it: you'll bang your head, get wet, slip, trip, type twice as much as you really needed to otherwise, be annoyed, exhausted or inconvenienced for no good reason and you might end up cursing it's so-called designer.

If a thing violates PONU due to a fundamental decision made during the thing's design phase, I call it a design-time PONU failure, or just DTPF or DTF.

Sometimes a thing seems to have been designed correctly, but when it came time to implement, build or install it, the people who did it made a mistake and deviated from the design. They may have done it because they were less intelligent, or weren't aware of the reasons for the original design or were rushed or chose to optimize away certain qualities in favor of reducing cost, for example. But regardless of the excuse, it causes it to violate PONU, and thus they have created a worse user experience, and worsened the human condition.

Here are some examples of everyday things that clearly violate PONU:

A pipe that leaks when water passed through it.

A computer that crashes after a few hours of simple word processing tasks. (MS Windows?)

A high-traffic public building in a cold windy city that has a single door to the outside (rather than a double-door or revolving door), and it's winter, and the door-closing-spring-mechanism thing is broken. And so every time a person passed through it a gust of cold winter air rushes into the building, hitting the poor folks sitting inside trying to stay warm, until somebody gets up and manually closes the door again. And the cycle repeats every minute or so with each new person to pass through it. (This is an example of both a design-time failure and a maintenance-time failure. But regardless it violates PONU.) There is a door in a downtown Chicago train station that's been doing this for the entire time I've lived in the area, which has been 2+ years. So clearly either the designer or maintainer of the facility is an idiot, in my judgment. It would be trivial to fix.

I believe all good ideas are eventually discovered by many people independently and so I'm sure that the principle I've described here has one or more "official" terms for it, probably in the areas of architecture or usability design. I wouldn't be surprised. But from my perspective I did develop this idea and term a long time ago, through personal observation and analysis, so I thought I'd blog about it here to share with others who may not have stumbled upon it before.

Focus Ambush

Software in a GUI desktop mode should not leap into the foreground.

I'm in the middle of typing something and SUDDENLY MY INPUT EVENTS ARE SENT to a completely different app than intended.
This causes bad things to happen, at worst. (Delete something? Agree to something I did not want to agree to?) And at best, it causes me to waste time, and to have to redo work I've already done. Or fix things that I should not have to fix.

Or....I'm in the middle of looking at something or reading something and SUDDENLY IT DISAPPEARS OR IS COVERED OVER by something completely different. Now I've lost my place, my focus, my rhythm. And you've increased my level of stress or discomfort. And I'm going to have to waste time restoring the desktop to it's previous state. And get a little older and closer to death, and have nothing positive to show for that extra chunk of time+energy you've caused me to throw away. Dumbasses.

There may be situations where it is absolutely and critically important that you do that. An emergency. Life or death is on the line, for example. If that is the situation, then yes, by all means, do it. But if that is not the case, then do not do that. Will my computer EXPLODE IN 5 SECONDS UNLESS I CLICK A CERTAIN BUTTON BEFORE IT'S TOO LATE?!?!?! No? Then don't leap into the foreground. Dumbasses.

I'm looking at you, Microsoft. You are the Poster Boy for this behavior. There are others that do it too, but your company's software has done it to me many times over the years, much more so than any other software or company. And due to the number of installations you have, I can conclude you've been doing it to millions of other people, probably billions of times, all together. All I can say is that, gee, it's 2007 now folks. There may have been an excuse for ignorance back in 1980. But it's 2007 now. Dumbasses.

If the hardware, operating system, desktop GUI and end-user applications are architected such that it's possible for the user to multi-task, then by all means, yes, allow them to multi-task. And do not unnecessarily disrupt or annoy them. Let me give one particular example of a real-world use case where I have a legitimate desire to do something on the computer without being bit by Focus Ambush.

To make good use of my time, I may tell the OS/GUI to launch an application that I know I will want to use or take a look at in the near future. But I also know that it will take a while for it to make itself ready for my use. So, in the meantime, rather than wait around sitting on my thumbs and wasting time, it would be smart if I do something else useful, in the meantime. Like read something. Use a different tool or application. BUT THEN SUDDENLY your app LEAPS into the foreground, stealing my visual focus and input events. There was no excuse for that. And the problem is worse when I have several apps running or in the middle of launching. Yes, I know that I launched your app. I told it to start. But you know what? Your OS/GUI also knows that I am doing something else or looking at something else on the screen, in the meantime. If you (by "you" I mean the OS/GUI) know that you are showing me something on the screen right now, and/or that I'm in the middle of typing something (because, say, you have a record of input events arriving from the keyboard/mouse within the last X seconds, for example.) then it is reasonable for you to assume that if your were to push a new app/window into the I/O foreground that you could cause Focus Ambush. That's a reasonable prediction for you to make, as the OS/GUI (or rather, as the writer of that OS/GUI). Therefore, a smarter alternative is to provide some other, less intrusive indicator of the fact that your app/window is "ready" or wants my attention. There are lots of ways of doing this, just pick one and go with it. Make a little "hopping" icon near the bottom of the screen, for example. Or play a gentle chirping sound. Or flashing. Once, repeating, whatever, even make it user configurable. Something. Anything like that would be better than leaping onto the screen, covering some pre-existing applications or document, and stealing input focus. That is so obviously a bad thing. At least the good news is that I have seen cases in modern apps and desktops where the GUI did do The Right Thing, sometimes. (I've gotten apps on Windows to flash themselves in the taskbar in the bottom of the screen, and had apps chirp and hop, on the Mac. Kudos to both. But it's not consistent, and not everybody does it, all the time.) (When I say obvious, I mean it is obvious to anyone who has actually used a computer, as an end-user or consumer. If all you did was design/build/code your computer/OS/GUI/apps WITHOUT having actually USED it, then yes, you may not have learned that that makes for a bad user experience. But it's like having a factory which produces cartons of some beverage, and the "mouth" of the carton, that a person would put their lips against to drink from, for example, has razor blades in it. Ouch. If all you did was design the factory and the carton and manufactured them, shipped them, gave a little CEO puff speech, advertised, did the accounting, etc. you may never realize just what a bad user experience you've caused. But the instant you try to drink from your carton the first time, ouch, you learn. All I expect is that you actually USE the thing you make. If you make food, eat it. If you make guns, shoot them. Chairs, sit on them. If you don't, you're a dumbass.) This behavior is understandable and acceptable in cats. They're just animals. If you're typing on the keyboard and suddenly a cat leaps onto it, disrupting your work, you have to accept it as The Cost of Having A Cat, because they're just "dumb" animals. We make the software. We did not make the cats. The cats are not our fault. The software is our fault. Humans are not (or rather, don't have to be) "dumb" animals. And software is just a set of rules or steps, written by humans, so we don't have to make it in such a way that it is obviously behaving like a dumb animal. If we do (if you do, whoever you are that made the software do this) then you, my friend, are a dumb animal. A dumbass. Again, excusable back in say 1980 (to pick a year in the past at random, but it's arbitrary). But it's 2007 now, folks. Wake up. Read the memo. The memo arrived QUITE a while back. It's there in your Inbox, if you only care to open your eyes. Dumbasses.

By the way, one of the reasons why I prefer to use the CLI/Terminal mode when Doing Real Work, rather than the GUI/Desktop mode, is that I know that I'll be almost entirely immune to Focus Ambush. It's not completely impossible to cause it in CLI/Terminal mode, but in practice, in most situations, it just doesn't happen. And that's great. You can work with a sort of serial, deterministic frame of mind. Or, you can also do things "in parallel" (by firing off background tasks or working with several terminals or shells open concurrently, spread across your desktop, each doing or showing something different, but all still useful and relevant), but even when you do tasks in parallel, in a CLI/Terminal mode, it's more controllable, predictable, flexible, and focus-friendly, than in the GUI/Desktop paradigm. Not all GUI/Desktop experiences are equal though, and some are more prone to Focus Ambush than others (Microsoft is more prone than Apple; older OS's/GUI's/apps by anybody are more likely to do it than more modern ones) but in general, choosing CLI/Terminal over GUI/Desktop is the smarter bet if you want to avoid Focus Ambush. One drawback to CLI/Terminal mode, however, is that the type of work you can do with it is usually better suited, or more biased towards, the work of a programmer or other computer techie. If you're an artist, and therefore you need to see and interact with a 2D or 3D graphical representation of your subject or medium then you may be stuck having to be in a GUI/Desktop mode most or even all of the time. But other than those two cases, which are probably the extreme opposite cases, there are many other cases that are more near the middle of the spectrum, in terms of their needs, and might be decently served using the CLI/Terminal mode. For tasks like accounting, heck, it might even be better! (I imagine using a combination of say Terminal, bash, vi and python to see, edit, calculate, re-calculate numbers and data sets, and perform data administration or management tasks. Could you do everything you needed to do in that environment with that tool set and paradigm? I dunno. Maybe not everything, it may be a compromise, but I bet you could do a lot. And at least you'd be insulated from Focus Ambush and the other ills of the GUI/Desktop approach. Like all the cognitive distractions and visual junk food that fills the screen. Think meaningless symbolic icons up the wazoo. Think advertisements. Purty colors. Animations for the sake of animations. But these latter things are not the subject of this article. Maybe another day.)

Focus Ambush is bad.
Don't do it unless absolutely necessary.
Where necessary means something like a case where someone will die, or something will explode, if you do not do Focus Ambush.

Grograma Delta: Purpose

I've started this new blog to serve as a place to post content that is both NOT related to my computer game startup, and NOT utter fiction or random silliness. Which basically means essays or posts about serious subjects. I had been posting a few items of the latter type on my fiction blog, Grograma Illusions, and it felt a little wrong to continue doing that.

Mike