Michael Eriksson's Blog

A Swede in Germany

Posts Tagged ‘usability

Eternal September? I wish! (And some thoughts on email)

leave a comment »

One of the most unfortunate trends of the Internet is that erstwhile standard procedures, behaviors, whatnot are forced out by inferior alternatives, as an extension of the Eternal September. Indeed, the point where even the Eternal September can be viewed with some nostalgia has long been reached:

The name arose through a combination of how, every September, the Internet would see a sudden burst of college freshmen, who still needed to learn how to handle themselves and who were an annoyance to older users until they had done so; and how the popularization of the Internet outside of college caused this inflow of unversed users to take place over the entire year. Even so, in the early days, the new users tended to be of over-average intelligence, tech affinity, and/or willingness to adapt—and many could still continuously be made to leave their newbie status behind. The problem with the Eternal September was its Hydra character: Cut of one head and it grew two new.

Today’s situation is far, far worse: There is no filtering* of who uses the Internet, be it with regard to intelligence, technical understanding, willingness to learn from more senior users, …; and, by now, the vast majority of all users are stuck in a constant newbie state. Indeed, we have long reached a point where those who have been on the Internet since before the problems became overwhelming** are viewed as weirdos for doing things the right way***. Worse: Websites are usually made for the “lowest common denominator”, with regard to content, language****, and interface, making them far less interesting than they could be to the old guard. This is paralleled in a number of negative phenomena on the Internet (and, unfortunately, IT in general): Consider e.g. how much less profitable it would be to spam a collective of STEM students than a random selection of the overall population, or how much less successful an Internet-based virus among the tech savvy.

*A formal filter, a legal restriction, an equivalent of a driver’s license, or similar, was not in place before the Eternal September either. However, Internet access outside of higher education was reasonably rare, and even within higher education it was far more common in STEM areas than in e.g. the social sciences. Correspondingly, there was an implicit filter that made it far more likely for e.g. a math major to have Internet access than for e.g. a high-school drop-out.

**The linked-to Wikipedia page puts 1993 as the start date in the U.S., but other countries like trailed somewhat. I started college in 1994 and the situation was reasonable for a few years more, before the Internet boom really started—after which is has been downhill all the way.

***Note that while there is some arbitrariness to all rules and there is usually more than one legitimate way to handle things, there is at least one important difference between the “old ways” and the “new ways” (even aside from the benefit of continuity and consistency, which would have been present with the old rules): The old ways were thought-out by highly intelligent people and/or developed by trial-and-error to a point where they worked quite well—the new are a mixture of complete arbitrariness; ideas by less intelligent and less experienced users, or even managers of some software company; attempts to apply unsuitable “real-world” concepts to the online world; … To this must be added the technical side: Someone who understands it, all other factors equal, is objectively better off that someone who does not—and less of a burden to others.

****Even Wikipedia, once an exemplary source of good writing, has gone downhill considerably, with regard to both grammar and style. (Notably, the “encyclopedic writing” aspect is increasingly disappearing in favor of a more journalistic or magazine style. I have long had plans for a more detailed post on Wikipedia, including topics like an infestation with unencyclopedic propaganda, but have yet to get around to it.)

A particularly depressing aspect, but great illustration of the more general problems, is the (ab-)use of email by many businesses, government institutions, and similar, who simply do not understand the medium and how to use it properly. No, I am not talking about spam here (although spam is a gross violation)—I am talking about everyday use.

Consider e.g.:

  1. That many businesses and virtually all (German) government institutions fail to quote the original text when replying and replace the subject line with something to the effect of “Your message from [date]”.

    The former makes it harder to process the message, in particular when a re-reply is needed, often forcing the user to open several other messages to check for past contents; the latter makes it much harder to keep messages together that belong together*, to find the right reply to an email, identify why a reply was sent**, etc. To boot, these problems likely contribute to poor customer service through creating similar issues on the other end, e.g. through a member of customer support not having all the information present without looking through old emails or some ticket system: Even if the information is there, access will be slower, more resources will be wasted, and there is a major risk that important information will still be missed.

    *Not only manually, but also through giving automatic “threading” mechanisms in email clients an unexpected obstacle.

    **When the original text is not included, this becomes even harder. In a worst-case scenario, when several emails were sent to the same counter-part on the same day (rare but happens), it might not even be possible to make the correct match—or only through comparing various IDs in the message headers. The latter is not only much more effort than just looking at subject lines, it also requires that all involved software components have treated them correctly, that the counter-part has used them correctly, and that the user knows that they exist…

    The explanation for this absolutely amateurish and destructive behavior is almost certainly that they have never bothered to learn how to handle email, and just unreflectingly apply methods that they used with “snail mail”* in the past. This is the more absurd since going in the other direction, and altering some snail mail procedures in light of experiences with email, would be more beneficial.

    *This phrase gives another example of how the world can change: Twenty years ago, I could use the phrase and simply assume that the vast majority of all readers would either know that I meant “physical mail sent by the post”—or be willing both to find out the meaning on their own and to learn something new. Today, while typing the phrase, I am suddenly unsure whether it will be understood—and I know that very many modern Internet users will not be willing to learn. I might be willing to give the disappearance of the phrase a pass: We can neither expect every phrase ever popular to continue to be so in the long term, nor the phrases of any group to be known in all other groups. However, the attitude towards learning and own effort is a different matter entirely.

  2. When messages are quoted, established rules are usually ignored entirely, especially with regard to putting the quote ahead of the answer and to intermingle quote and reply, which makes an enormous difference in the ease of processing the reply. Some tools, notably MS Outlook, more-or-less force a rule violation on the users… When quote and reply are intermingled it is usually not done in the established manner, with separating new lines and use resp. non-use of a “> ” prefix; instead, the new text is simply written straight into the old and separated only by a highly problematic* use of a different color.

    *Among the problems: The colors are not standardized. The result becomes confusing as to who wrote what in what order after just a few back-and-forths, to the point of making a lengthier email discussion almost impossible (whereas it was one of the main uses of email in the days of yore). It forces the use of HTML emails (cf. below). There is no guarantee that the colors will be visible after printing or a copy-and-paste action to another tool (notably a stand-alone editor). Not all email clients will be able to render the colors correctly (and they are not at fault, seeing that HTML is not a part of the email specifications). Generally, color should not be used to make a semantic differentiation—only to highlight it. (For instance, in the example below, an email client could automatically detect the various “>” levels and apply colors appropriately; however, the “>” signs must remain as the actual carriers of meaning.)

    To give a (simplistic and fictional) example of correct quoting:

    >>> Have you seen the latest “Star Wars” movie?
    >> No.
    > Why not?
    The one before that was too disappointing.

  3. Ubiquitous use of “no-reply” addresses: Anyone who sends an email has a positive duty to ensure that the recipient can reply to this email. This includes event-generated automatic messages (e.g. to the effect of “we have received your email” or “your package has just been sent”) and news letters. Either make sure that there is someone human able to read the replies or do not send the email at all.* This is not only an ethical duty towards the recipient, it is also a near must for a responsible sender, who will be interested in e.g. tracking resulting failures.

    *The exact role of this human (or group of humans) will depend on the circumstances; often it will be someone in customer service or a technical administrator.

  4. Abuse of email as just a cost-saver relative snail mail: There is nothing wrong with sending relevant attachments in addition to an email text, and in some cases, e.g. when sending an invoice*, even a more-or-less contentless email and an attachment can be OK (provided that the recipient has consented). However, some take this to an absurd extreme, notably the outrageously incompetent German insurance company HUK, and write a PDF letter containing nothing that could not be put in an email, attach the resulting file to the email, and use a boiler-plate email text amounting to “please open the attachment to read our message”. This, obviously, is extremely reader hostile, seeing that the reader now has to go through several additional steps just to get at the main message** and it ruins the normal reply and quote mechanisms of email entirely. To boot, it blows up the size of the message to many times what it should be*** and increases the risk of some type of malware infection.

    *This especially if the contents of the invoice are to some degree duplicated in the email proper, including total amount, time period, and due date (but more data is better). Writing an invoice entirely as a plain-text email is possible, and then the attachment would be unnecessary; however, there can be legitimate reasons to prefer e.g. PDF, including a reduced risk of manipulation, a more convincing and consistent visual appearance if a hard-copy has to be presented to the IRS, and an easier differentiation between the invoice proper and an accompanying message. (There might or might not be additional legal restrictions in some jurisdictions.)

    **Note that it is not just a matter of one extra click to open that one attachment that one time. Consider e.g. a scenario of skimming through a dozen emails from the same sender, from two years back, in order to find those dealing with a specific issue, and then to extract the relevant information to clarify some new development: If we compare a set of regular emails and a set of emails-used-to-carry-PDFs, the time and effort needed can be several orders larger for the latter. Or consider how the ability to use a search mechanism in the email client is reduced through this abuse of email.

    ***This is, admittedly, less of an issue today than in the past (but HUK has been doing this for a very long time…). Still there are situations where this could be a problem, e.g. when a mailbox has an outdated size limit. It is also a performance issue with regard to other email users: The slow-down and increase in resource use for any individual email will be relatively small; however, in the sum, the difference could be massive. What if every message was blown-up by a factor of 10, 100, 1000, …? What would the effects on the overall performance be and what amount of band-width and processing power (especially if spam or virus filters are applied) would be needed? For instance, the two emails at the top of my current mailbox are, respectively, an outgoing message from me at 1522 Byte and the reply to said message at 190 Kilo(!)byte—roughly 125 times as much. The lion’s part of the difference? A two-page PDF file…

  5. Use of HTML as an email format: Such use should, on the outside, be limited to recipients known both to handle the emails in a compatible manner and to be consenting: HTML is not supported by all email clients, and not in the same manner by all that do. It poses an additional security and privacy risk to the recipient. It bloats the message to several-to-many times the size it should be. It makes offline storage of the email more complicated. It makes it harder to use standard reply and quoting mechanisms. The risk of distortion on the way to the recipient is larger. … Notably, it also, very often, makes the email harder to read, through poor design.

    To boot, the reason for the use is usually very dubious to begin with, including the wish to include non-informative images (e.g. a company logo), to try to unethically track the recipients behavior (e.g. through including external images and seeing what images is retrieved when), or to make the message more aesthetic*. A particular distasteful abuse is some newsletters that try emulate the chaotic design of a commercial flyer or catalog, which often deliberately try to confuse the readers—either the newsletter senders are incompetent or they try to achieve something incompatible with the purpose of a newsletter**.

    *This is simply not the job of the sender: The sender should send his contents in a neutral form and the rendering should be done according to the will of the recipient and/or his email client—not the sender. Efforts to change this usually do more harm than good.

    **Most likely, but not necessarily, to use it as advertising. I note that while newsletters are often unwelcome and while the usual automatic addition of any and all customers to the list of recipients is despicable, the abuse of a newsletter for advertising is inexcusable: Many will consent to being or deliberately register as recipients because they are interested in news about or from the sender; and it is a gross violation of the trust placed in the sender to instead send them advertising.

    There are legitimate cases where a plain-text email is not enough to fulfill a certain use-case; however, they are rare and usually restricted to company-internal emails. For instance, one of the rare cases when I use HTML emails is when I want to send the tabular result of a database query to a colleague without having to use e.g. an Excel attachment—and even this is a border-line spurious use: In the days of yore, with some reservations for the exact contents, this could have been done equally well in plain-text. Today it cannot, because almost all email readers use a proportional font and because some email clients take inexcusable liberties with the contents*.

    *For instance, Outlook per default removes “unnecessary” line-breaks—and does so making assumptions that severely restrict the ability to format a plain-text document so that it actually is readable for the recipient.

    Of course, even assuming a legitimate use-case, it can be disputed whether specifically HTML is a good idea: Most likely, the use arose out of convenience or the misguided belief that HTML was a generic Internet format (rather than originating as a special purpose language for the Web). It would have been better to extend email with greater formatting capabilities in an ordered, centralized, and special-purpose* manner, as has been done with so many other Internet related technologies (cf. a great number of RFCs).

    *Which is not automatically to say that something should be developed from scratch or without regard for other areas—merely that it should be made to suit the intended purpose well and only the intended purpose. Some member (or variation of a member) of the ROFF-family might have been suitable, seeing that they are much closer to plain-text to begin with.

  6. A particularly idiotic mistreatment of emails is exemplified by Daimler and in recent discussion for another large auto-maker (which one, I do not recall):

    If an email is sent to an employee at the wrong time, e.g. during vacation, the email is simply deleted…

    The motivation given is absurd and shows a complete lack of understanding of the medium: This way, the private time of the employees would be protected. To make matters worse, the “threat” comes not from the outside but from a (real or imagined) pressure from within the company to always be available. In effect, Daimler has created a problem, and now tries to solve this problem through pushing the responsibility and consequences onto innocent third parties.

    Email is by its nature an asynchronous means of communication; and one of its greatest advantage is that the sender knows that he can send a message now, even outside of office hours or during vacation periods, and have it handled on the other end later. He does not have to consider issues like whether the recipient (if a business) is open or (if a person) is at home with his computer on. Moreover, the “later” is, with some reservations for common courtesy and stated dead-lines, determined by the recipient: He can chose to handle the email in the middle of his vacation—or he can chose to wait until he is back in the office. Whichever choice he makes, it is his choice; and if he chooses the former against his own best interests, well, then he only has himself to blame.

    By this utterly ridiculous rule, one of the greatest advantages of email is destroyed. To boot, it does this by putting an unfair burden on the sender, who is now not only required to re-send at a later and less convenient time—but who can see a number of additional disadvantages. Assume e.g. that the sender is about to head for his vacation, sends an important and urgent email, goes of the grid for two weeks, and comes back to see that his email has not even been read. Or take someone who writes a lengthy email and loses* any own copy after sending—should he now be required to re-type the entire thing, because of a grossly negligent policy of the recipient’s? Or what happens when employees in very different time zones or with very different vacation habits try to communicate with each other? Should the one work during his normal off-hours or vacation so that the other can receive the email during his time in the office? What happens if the notification** of “please send again” from company A is it self deleted by company B?

    *Disk crashes and accidental deletes happen; I have worked with email clients that do not automatically save sent emails; and, in the spirit of this post, not all users actually know how to retrieve sent emails that are saved…

    **Daimler apparently at least has the decency to send such notifications. I would not count on all copy-cats to follow suit.

    Want to keep your employees from reading company emails in their spare time? Do not give them email access from home or do cut it off during those times when no access is wanted! The way chosen by Daimler turns the reasonable way of handling things on its head—to the gross detriment of others. (This even assuming that the intended goal is legitimate: These are adults. We could let them chose for themselves…)

Advertisements

Written by michaeleriksson

January 5, 2018 at 12:54 am

Posted in Uncategorized

Tagged with , , , ,

Follow-up: On Firefox and its decline

leave a comment »

Since my post on the decline of Firefox, the developers have released another “great” feature, supposed to solve the speed problem compared to Chrome and other competitors: Electrolysis* (aka. e10s).

*I have no idea how they came up with this misleading name. Possibly, they picked a word at random in a dictionary?

This feature adds considerable multi-threading capability and detaches the GUI from the back-end of the browser, thereby on paper making the browser faster and/or hiding the lags that do occur from the user.

In reality? In one browser installation* (shortly after the feature being activated) I had to disable this feature, because it caused random and unpredictable tab failures several times a day, forcing me to “restart” (I believe the chosen word was) the tab in order to view it again. Even the tabs that did not need to be restarted only displayed again with a lag every time another tab had failed. The net effect was not only to make the browser more error prone, but also to make it slower (on average).

*I have several Firefox (more specifically Tor Browser) installations for different user accounts and with different user settings, including e.g. separate installations for business purposes, private surfing, and my WordPress account. This to reduce both the risk of a security breach and the effects of a breach, should one still occur. As for why the other installations were not affected, this is likely due to the roll-out manner used by Firefox of just activating a feature in existing installations, based on an installation dependent schedule, instead of waiting for the next upgrade. Presumably, all the other installations had received upgrades before being hit by the roll-out. (This approach is both ethically dubious and a poor software practice, because it removes control from the users, even to the point of risking his ability to continue working. What if something goes so wrong that a down-grade or re-install is needed—with no working browser installed? This is very bad for the private user; in a business setting, it could spell disaster.)

Today, I had to deactivate it in another installation: After opening and closing a greater number of tabs, Firefox grew more and more sluggish, often only displaying a page several seconds after I had entered the tab, or showing half a page and then waiting for possibly 5–10 seconds before displaying the rest. This for the third time in possibly a week after my latest upgrade. (I would speculate on some type of memory leak or other problem with poor resource clean up.)

I note that I have never really had a performance problem with Firefox (be it with pure Firefox or the Tor Browser*) before this supposed performance enhancer, possibly because I use few plug-ins and have various forms of active content (including Flash and JavaScript) deactivated per default—as anyone with common sense should. This makes the feature the more dubious, because it has (for natural reasons) taken a very large bite out of the available developer resources—resources that could have been used for something more valuable, e.g. making it possible for plugins like “Classic Theme Restorer” to survive the upcoming XUL removal.

*Not counting the delays that are incurred through the use of Tor. I note that Tor is a component external to the Tor Browser, and that these delays are unrelated to the browser used.

Unfortunately, the supposedly helpful page “about:performance”, which was claimed to show information on tabs and what might be slowing the tabs down, proved entirely useless: The only two tabs for which information was ever displayed were “about:config” and “about:performance” it self…

Oh, and apparently Electrolysis is another plugin killer: The plugin makers have to put in an otherwise unnecessary effort in order to make their plugins compatible, or the plugins will grow useless. Not everyone is keen on doing this, and I wish to recall (from my research around the time of the first round of problems) that some plugins face sufficiently large obstacles that they will be discontinued… (Even the whole XUL thing aside.)

Now, it might well be that Electrolysis will prove to have a net benefit in the long term; however, we are obviously not there yet and it is obvious that the release(s) to a non-alpha/-beta tester setting has been premature.

Written by michaeleriksson

November 6, 2017 at 11:02 pm

On Firefox and its decline

with one comment

I recently encountered a blog post by a former Firefox insider discussing its declining market share.

When it comes to the important question “why?”, he offers that “Google is aggressively using its monopoly position in Internet services such as Google Mail, Google Calendar and YouTube to advertise Chrome.”—which cannot be more than a part of the truth.

If it were the entire truth, this would mostly show in new or inexperienced users going to Chrome instead of Firefox, those that have not yet grown accustomed to a particular browser.

Then why is there a drop among the long-term users? Those who have used Firefox for years? Those who (like me) first used the Firefox grandfather Mosaic well over twenty years ago and then graduated to its father, Netscape?

Things like that happen either because the competition grows better (or better faster) or because the own product grows worse. Indeed, this is what I have repeatedly experienced as a user: After Netscape, I switched to Opera for a number of years, because Opera actually was a better browser, especially with its tabs. Year for year, Opera failed to add new useful features and tried to force-feed the users poorly thought-through ideas that some manager or developer out of touch with his users saw as revolutionary. Eventually, I gave up and moved over to Firefox, which at the time did a reasonable job and had over-taken Opera—not because of its own qualities, but because Opera declined.

Unfortunately, Firefox has gone down the same destructive path as Opera followed, has grown worse and worse, and the only reason that I am still with Firefox is that I use the “Tor Browser Bundle”, which is based on Firefox and recommended as the safest way to use Tor by the Tor developers.

To list all that is wrong with Firefox and its course would take far too long—and would require digging through many years* of memories of “for fuck’s sake”–memories.

*I am uncertain how long I have been using Firefox by now. In a rough guesstimate, the Opera-to-Firefox switch might have occurred some ten years ago.

However, to list some of the most important (often over-lapping) issues:

  1. The removal of preferences that should be standard, e.g. the ability to turn images and JavaScript on and off. If these remain at all, they are pushed into the infamous, poorly documented, and unreliable “about:config”—the use of which is strongly discouraged by Firefox.

    When such preferences are removed (respectively moved to “about:config”) the handling can be utterly absurd. Notably, when the setting for showing/not showing images in web pages was removed, the Firefox developers chose to defy the stated will of the user by resetting the internal setting in about:config to the default value…

    To boot, config switches that are in “about:config” often stop working after some time, merely being kept to prevent scripts from breaking, but no longer having any practical function. Among the side-effects is that someone finds a solution for a problem on the Internet, alters the configuration accordingly—and has to spend half-an-hour researching why things still do not work as intended. (The reason being that the solution was presented for an earlier version of Firefox and Firefox failed to make clear that this solution was no longer supported.)

  2. Forcing users to download add-ons to handle tasks that a good browser should have in its core functionality, while adding nice-to-haves appropriate for an add-on to the official interface… (The “sync” bullshit is a good example.) Worse: Not all add-ons are compatible with each other (or with every Firefox) version, making this road unnecessary problematic, with results including even browser crashes. To boot, any additional add-on increases the risk of a hackable vulnerability, data being leaked to a hostile third-party, or similar.
  3. Failing to add functionality that would be helpful, e.g. a possibility to disable the design atrocity that is “position:fixed” or a user-friendly mechanism for mapping keys.
  4. One truly great (and expectedly oldish) feature of Firefox is the ability to save tabs and windows when exiting or the browser crashes and have them restored on the next start. This especially since Firefox crashes more than most other applications.

    Unfortunately, the configuration of this feature is a bitch (and probably disabled by default). There are at least two (likely more; it has been a while since I dealt with this the last time) flags that have to have the right value for this to work—one of which should rightly be entirely independent*. The names of these settings in about:config and the description in the GUI are non-obvious, more-or-less forcing a user to search the web for information—if he is aware that the feature exists in the first place. And: In several releases this feature has been so bug ridden that no combination of settings has worked…

    *The one appears to control the feature; the other controls whether a warning is issued when a user tries to close more than one tab at a time. When the latter is disabled, which is very reasonable even for someone who uses the former, the former is ignored…

    Worse, without this functionality a simple “CTRL-q” just quits the browser—no confirmation, no tabs saved. For a power surfer who regularly has dozens of tabs open at the same time, this is a major issue. This is the worse since someone heavy on tabs is almost certainly a frequent user of “CTRL-w”* and there is no good native way to change key bindings—amateurish!

    *I.e. “close the current tab”. Note that “w” is next to “q” on a standard QWERTY-keyboard, making the likelihood of occasional accidents quite high.

  5. The config management is lousy.

    For instance, Firefox started with the Windows style concept of “one user; one configuration” and never added provisions to e.g. specify config files on the command line. Among the negative side-effects is the later need to invent the redundant and poorly implemented concept of a “profile”—confusing, user-unfriendly, and bloating the code.

    For instance, “about:config” provides many, many options of the type normally found in a config file, that could have been edited with a text-editor much more comfortably than over the about:config interface. However, this opportunity was not taken and the users are stuck with about:config. Actually, there are some type of files, but these are absurd in comparison with those used by most Linux applications—and it is very, very clear that users are supposed not to edit them. (Statements like “Do not edit this file.” feature prominently.) For example, Firefox uses user_pref(“ui.caretBlinkTime”, 0); where any reasonable tool would use ui.caretBlinkTime=0.

    For instance, there is so much secrecy about and inconsistency in the configuration that the standard way to change an apparently simple setting is to install an add-on… (Also cf. above.) Where a user of a more sensible application might be told “add x=y to your config file”, the Firefox user is told to “install add-on abc”…

    For instance, copying the configuration from one user to another fails miserably (barring subsequent improvements), because it contains hard-coded paths referring to the original user.

    For instance, it used to be the case that a Firefox crash deleted the configuration, forcing the user to start over… (This was actually something that kept me with Opera for a year or so after I was already thoroughly feed up with it.)

  6. The support for multi-user installations, the standard for Linux and many corporate Windows installations, is weak and/or poorly documented. The results include e.g. that all users who wants to use popular add-ons have to install them individually—and keep them up-to-date individually.

    (Disclaimer: I looked into this on several occasions years ago. The situation might have been improved.)

  7. There are a number of phone-home and phone-third-party mechanisms that bring very little value, but often pose a danger, e.g. through reducing anonymity. This includes sending data to Google, which I would consider outright negligent in light of Google’s position and how it has developed over the years.
  8. The recent, utterly idiotic decision to drop Alsa support in favour of Pulse on Linux. This decision is so idiotic that I actually started to write a post on that topic alone when I heard of it. Most of what I did write is included as an excursion below. (Beware that result is not a full analysis.)
  9. The address bar started of very promisingly, e.g. with the addition of search keywords*. Unfortunately, it has so many problems by now that it does a worse job than most other browsers—and it grows worse over time. The preferred Firefox terminology “awesomebar” borders on an insult.

    *For instance, I have defined a keyword so that when I enter “w [something]”, a Wikipedia search for “[something]” is started. “ws [something]” does the same for the Swedish version of Wikipedia; “wd [something]” for the German. (I have a number of other keywords.)

    Among the problems: If a page is loading slowly and I re-focus the address bar and hit return again, the obvious action to take is to make a new attempt to load this page—it does not: It reloads the previous page! The history suggestions arbitrarily excludes all “about:” entries and all keyword searches—if I search with “w [something]” and want to switch to “g [something]”*, I have to retype everything. Per default, for some time, the history functionality is weakened through not listing the potential matches directly, but preceding them with annoying and useless suggestions to “visit” or “search” that only delay the navigation and confuse the users. Moreover, while there used to be working config flags to disable this idiocy, there are now just config flags (that do not work)…

    *Used to mean “search with Google” a long, long time ago; hence the “g”. Currently, I use duckduckgo.

  10. The layout/design and GUI (including menu handling) have been drastically worsened on several occasions.
  11. Many of the problems with Firefox can be remedied with “Classic Theme Restorer” (an absolute life-saver) or similar “user empowering” add-ons. Unfortunately, these all use the “XUL-framework”*, which Firefox has decided to discontinue. There is a new framework for add-ons, but it does not support this type of functionality (whether “yet” or “ever” is not yet clear). Many of the most popular add-ons, including “Classic Theme Restorer”, will therefore not be able to provide the full scope of functionality and at least some of them, again including “Classic Theme Restorer”, will be discontinued by their developers when XUL is turned off.

    *In a twist, XUL was once considered a major selling point for Firefox.

    My poor experiences with Firefox and the absurd attitudes of the Firefox developers might have made me paranoid—but I cannot suppress the suspicion that this is deliberate, that the add-ons that allow users to alter the default behaviors are viewed as problems, as heretics to burn at the stake.

To this should be added that since the switch from a “normal” versioning scheme to the idiocy of making allegedly major releases every few months*, the feature cramming has increased, with a (very predictable) increase in the number of run time problems. The Firefox makers were convinced that this would turn Firefox from a browser into a super-browser. In reality, this only resulted in hastening its demise—in much the same way that a TV series fighting for its survival ruins the good points it had left and drives away the remaining faithful**. If in doubt, most people who try to jump the shark are eaten…

*I.e. making version jumps of 44 to 45 to 46, instead of 4.4 to 4.5 to 4.6 or even 4.4.0 to 4.4.1 to 4.4.2.

**A topic I have been considering recently and intend to write a blog post on in the close future.

Sadly, the delusional author of the discussed article actually makes claims like “Firefox is losing despite being a great browser, and getting better all the time.”—turning the world on its head.

Excursion on the competition:

Unfortunately, Firefox could still be the lesser evil compared to the competitors. Chrome/Chromium, e.g., has many strengths, but configurability and adaptabtility to the user’s needs are not among them; on the contrary, it follows the deplorable school of achieving ease of use through reducing the controllable feature set—the equivalent of Apple’s infamous one-buttoned mouse. Chrome is entirely out of the question for anyone concerned with privacy; while its open-source sibling chromium (in my possibly incorrect opinion) trails Chrome in other regards. I have not tried Opera for years; but combining the old downwards trend (cf. above) with the highly criticized platform shift that almost killed it, I am not optimistic. Internet Explorer and Edge are not worthy of discussion—and are Windows only to begin with. Safari, I admit, I have never used and have no opinion on; however, it is Mac only and my expectations would be low, seeing that Apple has pioneered many of the negative trends in usability that plague today’s software. Looking at smaller players, I have tried possibly a dozen over the years. Those that have been both mature and user-friendly have been text-based and simply not worked very well with many modern web sites/designs, heavy in images and JavaScript; most others have either been too minimalistic or too immature. A very interesting concept is provided by uzbl, which could, on paper, give even the most hard-core user the control he needs—but this would require a very considerable own effort, which could turn out be useless if the limited resources of uzbl dry up.

Excursion on the decline of open source:

It used to be that open-source software was written by the users, for the users; that the developers were steeped in the Unix tradition of software development; that they were (on average) unusually bright and knowledgeable; … Today, many open-source projects (e.g. Firefox, Libre-/OpenOffice, many Linux Desktop environments) approach software development just like the commercial firms do, with an attitude that the user should be disenfranchised and grateful for whatever features the projects decided that he should like; quality is continually sacrificed in favour of feature bloat (while central features are often still missing…); many of the developers have grown up on Windows or Mac and never seen anything better; … Going by the reasoning used by many Firefox developers in their bug tracking tool, Firefox appears to have found more than its share of people who should not be involved in software development at all, having poor judgment and worse attitudes towards users.

Excursion on Pulse:

(Disclaimer: 1. The below is an incomplete version of an intended longer analysis. 2. At the time the below was written, I had a few browser tabs open with references or the opinions of others that I had intended to include. Unfortunately, these went missing in a Firefox crash…)

The reasoning is highly suspect: Yes, supporting two different sound systems can be an additional strain on resources, but this decision is just screwed up. Firstly, they picked the wrong candidate: Pulse is extremely problematic and malfunctioning so often that I would make the blanket recommendation to de-install it and use Alsa on almost any Linux system. Moreover, Pulse is not a from-scratch-system: It is an add-on on Alsa and any system using Pulse must also have Alsa installed—but any system can use Alsa without having Pulse. Not only will more users have access (or potential access) to Alsa, but good software design tries to stick with the smallest common denominator to the degree possible. Secondly, at least one abstraction already exist that is able to abstract multiple sound systems on Linux (SDL; in addition, I am semi-certain that both Alsa and Pulse provides backwards compatibility for the older OSS, which could have been used as a workaround). Thirdly, if none had existed, the proper Open Source way would have been to create one. Fourthly, a browser maker who tries to dictate what sound system a user should use have his priorities wrong in an almost comically absurd manner. (What is next? KDE only? Kaspersky only? Asus only?) Notably, there are very many Linux users who have made a very deliberate decision not to burden their systems with Pulse—and have done so for very good reasons*.

*Including how error prone it is, a too-high latency for many advanced sound users, the wish for a less bloated system, or Pulse’s straying too far from the classical principles behind Unix and Open Source software. Do an Internet search for more details on its controversy.

A particular annoyance is that the decision is partly justified by the claim that statistics gathered by Firefox’s phone-home functionality would indicate that hardly anyone used Alsa—which is extremely flawed, because many Linux distributions and individual educated users disable this phone-home functionality as a matter of course. Since the users who have a system with phone-home enabled are disproportionally likely to be unlucky/careless/stupid enough to also use Pulse, the evidence value is extremely limited.

Written by michaeleriksson

July 26, 2017 at 9:51 pm

Focus stealing—one of the deadly sins of software

leave a comment »

Experimenting with the (currently very immature) browser Aroraw, I re-encountered one of the deadly sins of software development: Presumptuous and unnecessary focus stealingw.

While I, as a Linux user, am normally not met with many instances of this sin, they are the more annoying when they do occur. Notably, they almost exclusively happen when I am off doing something completely unrelated on a different virtual desktopw, with the deliberate intention of finishing one thing and then revisiting the (as it eventually turns out) focus-stealing application once I am done or in five minutes. This re-visiting would include checking any results, answering any queries, giving confirmations, whatnot. Instead, I am pulled back to the focus-stealer mid-work, my concentration is disrupted, I have to switch my own (mental) focus to something new in a disruptive manner, and generally feel as if someone has teleported me from a (typically pleasant) situation to another (typically unpleasant).

There are other very good reasons never to steal focus, including that a typing or mouse-clicking user can accidentally cause an unwanted action to be taken. Consider, e.g., the user who is typing in a document, hits the return key—and sees the return being caught by a focus-stealing confirmation window, which interprets the return key as confirmation. In some cases, the user would have confirmed anyway, but in others he would not—and sometimes the results can be down-right disastrous.

Focus stealing is stealing: If an application steals focus, it takes something that is not its to take. Such acts, just as with physical property, must be reserved for emergencies and duress. Normally criminal acts can be allowable e.g. if they are needed to avert immediate physical danger; in the same way, focus stealing can be allowed for notifications of utmost importance, e.g. that the computer is about to be shut-down and that saving any outstanding work in the next thirty seconds would be an extremely good idea. Cases that are almost always not legitimate include requesting the user’s input; notification that a download is complete or a certain step of a process has been completed; and (above all) spurious focus stealing, without any particular message, because a certain internal state has changed (or similar).

“But some users want to be notified!!!”: This is not a valid excuse—we cannot let non-standard wishes from one group ruin software for another group. If there is a legitimate wish for notification (and most cases of focus stealing I have seen, have not been in situations where such a wish seemed likely to be common—even when allowing for the fact that different users have different preferences) other ways can be found than unwanted focus stealing. Consider e.g. letting the user specifically request focus stealing (more accurately, in this case, “focus taking”) for certain tasks by a checkbox or a configuration option (which, obviously, should be off per default), using a less intrusive notification mechanism (e.g. a notification in a taskbar or an auditory signal; may be on per default, but must be deactivatable), or the sending of an email/SMS (common for very long-running tasks and tasks on other computers; requires separate configuration).

As a particularity, if something requires a user involvement (e.g. a confirmation) before the application can continue, there is still only rarely a reason for focus stealing. Notably, users working on another desktop will almost always check-in regularly; those on the same desktop will usually notice without focus stealing; and there is always the above option of notification by other means. Further, for short-running tasks, it is seldom a problem that the user misses a notification—and he may well have physically left his computer for a long-running task.

Finally, any developer (in particular, those who feel that their own application and situation is important enough to warrant an exception) should think long and hard on the following: He may be about to commit one of the other deadly sins, namely over-estimating how important his application is to others. (Come to think of it, the applications that have stolen focus from me under Linux have usually been those of below average importance—the ones I use every now and then, or only use once or twice to see if they are worth having.)

Written by michaeleriksson

May 13, 2010 at 8:59 pm