It'd be very, very nice if devices with re-flashable memory had a physical write-enable switch on it. No, not a software switch. With physical write-enable, no more malware getting installed on them.
Everything with a battery should have an off switch
451–460 of 613 posts
Re: Everything with a battery should have an off switch
#452Earlier quoted context omitted.
Hum... He clearly says that engineers have ideas that are antagonistic to interaction design. There is an implied message that they can learn not to, but one message is explicit, the other is implicit. And it gets much worse in "The Inmates are Running the Asylum", that says engineers shouldn't do design right in the title, on the most sensationalist way possible. Later he toned down that message a lot. Nothing from…
Regardless of what the book says, anyone too close to the product during its development will have difficulty designing it appropriately for the user. If you know how the product works then you already have a mental model of interacting with it. That mental model is NOT the same as the user will have, and thus an engineer will think that something is obvious even though it is not obvious to the user. The same goes wi…
That's correct, and the designer is too close to the product too.
That is the correct message, and the one every article about design should push. Neither the engineers nor the designers can design a product in a vacuum.
Those are both old books that do not deny this message, but focus on less relevant subjects, and have less than clear advice. We shouldn't recommend those books for people without previous knowledge on UX design, because they will be harmful.
Besides, given that Nielsen was himself a very important voice on the creation of the modern user-focused design, there is very likely a newer book from him to recommend instead (I stopped reading his books and started reading his papers at the time of the change, so I don't know one).
Re: Everything with a battery should have an off switch
#453Earlier quoted context omitted.
Does anyone remember Office 2013 with the UPPER CASE MENUS? They were bad enough, but then Visual Studio 2013 HAD THEM TOO. That was triply bad: ugly, took more screen width than Mixed Case, and perhaps worst of all, to a programmer they looked like errors. Most of the languages we work with are case sensitive, so FILE and File look like two different things. It was a constant irritant. The chief designer for VS2013…
> "We decided to keep the uppercase menus because we want more energy in this part of the interface." It always seems to be new-age mumbo jumbo with these sort of design people. Design needs to be given back over to the engineers again. I know that suggesting is going to draw ridicule; it's easy and popular to point to the worst engineer-designed interfaces to ridicule the design abilities of all engineers. But form…
Design needs to be given back over to the engineers again.
No, no, then you get the open source approach:
In case the desktop shortcut for your application is not available with the /usr/share/applications/ directory you have and option to create the Desktop launcher manually. In this example we will create and Desktop application shortcut for Skype application. Obtain the following information for any given application you wish to create shortcut for. Below you can find an example:
Path Application Icon: /snap/skype/101/meta/gui/skypeforlinux.png
Application name: Skype
Path to executable binary: /snap/bin/skype
$ which skype
/snap/bin/skype
Re: Everything with a battery should have an off switch
#454Earlier quoted context omitted.
I get that you're pissed, but there's plenty of technology that you seemingly forget about (being pissed off makes you a bit irrational) that works most of the time. Saying nothing ever fucking works is just a dumb take
Btw, here is the litany of broken systems that led to my outburst above. I'm two months (at least) without data on my phone. I didn't need to use it and I'm a lazy ass so I didn't try to fix it. When I call them, a kind youg man on the other end of the chat says he's reset my service and within a couple of hours I'll definitely have data. In a couple of hours I have no data, but now I also have no service: "emergency…
I could make and receive iphone calls, I could hear the other party, but nobody could hear me. This went on for a couple days, I was ready to go get a new phone.
Then, silly me, I remembered the good old DOS days. I did a cold reboot of the phone, and voila! people could hear me.
Re: Everything with a battery should have an off switch
#455Earlier quoted context omitted.
> But now I think it's just a humdrum industrial eyesore. That was a popular opinion when it was built. Eventually it became iconic, but nevertheless I don't see many cities rushing to build their own.
https://en.m.wikipedia.org/wiki/Eiffel_Tower_replicas_and_de...
I know, I've seen a few of those. Most of them are tiny replicas built ironically for the novelty factor. Besides the ones built for tourist traps, most are justified as radio towers. But as radio towers the design is laughably obsolete. Compare with guyed masts, which virtually every developed town and city around the world has numerous examples of.
Re: Everything with a battery should have an off switch
#456Earlier quoted context omitted.
I don't mean to nitpick, but please refer to my comment regarding the inability of being able to inventory everything that can possibly go wrong in a computerized system. That's especially true given that if you take any successful engineering project, you'll see that its useful lifetime usually spans several individual engineering careers. Take something like Windows, or even Android for example. The people who were…
For the example you gave, as a user, what would you do with "Error: 0xFHJAD1234"? The best you could do is report it to Apple (or whoever). But, the error alone doesn't achieve anything. You would have been better off with "Something broke, click here to send log to Apple." (which is roughly what the book recommends - replace the error with something actionable).
You are making the same error as the book: assume that every user is non-knowledgeable, helpless and stupid, and that no user has access to a trusted expert to help them (whether for free or for a fee). And by designing for that error, it will become true. And knowledgeable, capable and smart people will resent you for it.
Re: Everything with a battery should have an off switch
#457Earlier quoted context omitted.
> Compare it to Linux UIs where you often have to grab a single pixel border on a 4k monitor to resize a window. On Linux you hold the super/windows key and click/drag anywhere on the window to move it, or right-click/drag anywhere on the window to resize it. It's much easier than using thick borders. Discoverability is admittedly not great, but this feature easily coexists with window borders. Microsoft could keep t…
Translation: “Don’t do it the way everyone else does it or the way you’ve always done it; our designer decided to make that hard for and instead we offer this hard-to-discover non-idiomatic workaround. “You will grow to love the workaround because it doesn’t hurt nearly as much, kind of like stopping after you’ve been hitting yourself in the head with a hammer.”
I guess you (deliberately) missed the part where the two features coexist perfectly fine. There is no "“Don’t do it the way everyone else does it", you pulled that out of your ass. All the Linux DEs worth mentioning have draggable window borders that are familiar to any Windows or MacOS user. The default width of those borders varies, but thick borders by default are common.
Re: Everything with a battery should have an off switch
#458Earlier quoted context omitted.
For the example you gave, as a user, what would you do with "Error: 0xFHJAD1234"? The best you could do is report it to Apple (or whoever). But, the error alone doesn't achieve anything. You would have been better off with "Something broke, click here to send log to Apple." (which is roughly what the book recommends - replace the error with something actionable).
And then what? Is Apple going to receive the error log and dispatch a technician to your house to fix it? In my experience sending crash data to software companies has never resulted in my satisfaction, nor has using some 'wizard' to diagnose an error. As alluded to above these systems are just not smart enough to actually know what's wrong. If the original programmers could create a fully automated flow to repair al…
Apple doesn't have to lift a finger beyond showing an error message with some kind of identifier. The user isn't expecting an onsite visit anyway. They can go to the local Apple store and explain the issue to an employee there, instead of wasting time trying to reproduce the error.
If they're not tech-savvy (and you would never talk to Apple store employees besides at the checkout counter if you were), they likely won't be able to reproduce the error anyway. They'd fumble around trying to explain what went wrong, and the employee would run through multiple scenarios trying to reproduce it.
Re: Everything with a battery should have an off switch
#459Earlier quoted context omitted.
It's a book actually: The Design of Everyday Things
That's such a godawful book. In my view it epitomizes everything that is wrong with design today. And the worst part is that comments like these make it come off as the go-to reference to actually solving these problems. The reasons it's the worst design guidance out there is that it teaches: 1) that engineers should NOT be entrusted/involved with user design. 2) to conceptualize users as blissful idiots. 3) that obs…
There's an endless debate in programming languages about how to handle errors in software. Error codes, exceptions, optional types, NaNs.
One solution I try is to redesign the cause of the error out of the system. For example, compilers often have maximum quantities of language constructs that are supported, like the maximum length of a string literal. Then, when the length is exceeded, an error message is concocted and generated, then error recovery has to be done, then the compiler has to not generate an object file, etc.
I don't know what other compilers do, but one day I realized that it was less work in the compiler to not have a limit, but to keep enlarging the string literal buffer. There was only one limit left on all these things, that was globally running out of memory. Globally running out of memory is a fatal error for compilers, and so error recovery isn't necessary. Just print a message and exit.
This works great. Large numbers of errors just go away, like "line length too long", "string literal too long", "too many cases in switch statement", "too many symbols", etc.
There are, of course, still some limits, like the object file formats often have hard limits, and of course you don't want to overflow the program stack.
Re: Everything with a battery should have an off switch
#460I like to walk into cell phone stores and ask if they have any phones with an off switch. These are of course rare and only sold by niche companies like Pine and Purism. Everything else just looks like it is off while it is still transmitting in low energy mode.