Refresh Is Sacred
tbray.org
tbray.org
Upon searching for a manual sync option (that would have to be a trivial addition) I came upon this issue[1]:
"No, adding an action for this would be a hack. The whole point of SparkleShare is to sync stuff automatically.... Just because something is easy to do doesn't mean it should be added."
I haven't touched Sparkleshare since.
Its TL;DR is this: this software is magic. It syncs automagically. You, the dumb user, are not supposed to know and care when it syncs or if it succeeds (hint: it's magic, it always does), and you're especially not supposed to tell the program that it has to do a sync. If your company's firewall interferes with the magic, go talk to your company IT.
The article sums up the issue perfectly: sometimes, as a user, I know better when the program is mistaken than the program itself. I should have a way to force it to refresh its state.
Which is a little unfair to Microsoft, since they do have a fair bit of functionality only slightly hidden on Windows.
Gaps in the "recent files" coverage are always so noticeable over all the environments too.
This example of a trend in current software development is extremely annoying and disturbing.
If your software is suppose to behave like magic, you had better make DAMN sure that it ALWAYS behaves like magic.
AND do it at the design stage, AND taking account of every possible unexpected input, AND fully verifying the code, AND adding checks on both the client and server side, AND adding fail-safes so that when the checks fail the software recovers properly, AND doing this for every damn feature.
But this presumptuous twat of a developer, obviously thinks that his first-cut at some agile magic code is perfect (and for a File-Syncing app no less!?!) and it is just the users that are foolishly wanting to mess up his ever-so-cool design.
And this is just one of thousands infesting our software development world today thinking that their ability to remove controls from the user is 'cool'.
If you have this attitude, it doesn't matter if you work for Google or some no-name startup -- you should leave. Now. You should not be building anything.
You are building a tool for the user, not a piece of art to be admired in a museum. Tools have user interfaces. Just as it is your job to avoid 10000 controls/widgets/menu options, it is also your job to give users a usable amount of controls appropriate to the task, and also to provide recovery options, like refresh, and preferably some control over how those controls appear ('Clean Screen' vs 'Advanced'...).
get practical /<rant>
edit fmt
Quite sure there's a few of us, if you need to emphasise anything perhaps being more succinct is better than subscribing to this form of communication.
I'm also disappointed in the formatting: I meant only the first sentence to have a mid-sentence all-caps. The list of "AND..." items was supposed to be just that, a list, each on it's own line with those as the bullet point leaders. Sadly, it refused to format as I entered it and mangled it all into one paragraph, and I didn't have time to take more than one shot at fixing/debugging it.
At least, though it was an imperfect post, there are those who liked it.
> Something I would consider is a hidden way to do this that's more convenient, like having an Alt modifier on the menu that changes "Add Remote Project..." to "Force Sync" or something like it, since obviously SparkleShare isn't perfect. Although I'm not going to write it and it would have to work on every OS which could make it a considerable task...
Then lower down another user expressed interest in dev'ving that for one of the three supported platforms:
> I suppose a hidden way is better than none. I'd be willing to contribute a patch for the Linux side of the house, if one is available for another platform for comparison.
Finally, the author mentioned at the bottom something about redoing notifications before closing the issue.
So when you wrote, "I haven't touched Sparkleshare since," did you mean since reading that single post you quoted? Or did you continue reading the rest of the posts from that same day which I quoted, and then decided that you didn't want to contribute nor interact with potential contributors to help solve that issue in the way the maintainer offered?
...
That's the part that really makes me scratch my head. Why would you want to hide the option, especially if doing so requires a lot of work on multiple OSes? Add a menu option to force a sync, problem solved.
> Then lower down another user expressed interest in dev'ving that for one of the three supported platforms:
Which doesn't really help, because he was already told that's not enough, and the feature has never been added.
> So when you wrote, "I haven't touched Sparkleshare since," did you mean since reading that single post you quoted? Or did you continue reading the rest of the posts from that same day which I quoted, and then decided that you didn't want to contribute nor interact with potential contributors to help solve that issue in the way the maintainer offered?
It doesn't do what I need it to do, and I don't have a few hundred hours to figure out how to create a hidden menu item on three OSes, so yes, I haven't touched it since 2012.
"It just works" isn't always best - especially when dealing with cross-device data sync - I know it isn't magic, I'm not "fooled", I know it's actually data that needs to be transferred to the new device. Hiding that, not giving me the option to force sync and see the progress of it is a very frustrating experience when I can't see passwords (or any state) that I'm expecting to see.
It does have a sync button doesn't it? 'Settings', 'Sync' on iOS. When you press it you can see the progress. Or do you mean something else.
I use purely Dropbox for it, if that matters.
For example, this is imho one of the most important features of WhatsApp, the little checkmarks that tell you, in one tiny little graphic, whether your message has been sent, received, or viewed. This is just so important to the user experience. I feel that app developers that ignore that users need to know what the app is doing, what state it is in, are just ignorant of human psychology and how we interact with machines. We don't want "magic", we don't want to "trust", we want to be informed and to know what is happening. Doing this is a streamlined way, little unobtrusive checkmarks for example, is UX gold.
It's like the close door button in US elevators.
Strong choice of word.
I've lost count of how many times I've pulled to refresh on a scrollable view in an app that doesn't refresh that way. Feels bad man.
The close door button is retained for emergency manual operation, not as a placebo button (they are disabled in normal, non-emergency operation because of ADA minimum open time rules to accommodate wheelchair-bound passengers.)
Some US elevators. The one at my office works fine, at least after the door has been open for a short time. I've done timing tests with a stopwatch to make sure I wasn't misjudging or misperceiving things. The door is open normally for N seconds and there is a threshold, T, such that if the button is pressed at time P, where P is in [T, N], the door starts closing immediately. I don't remember the details now, but T was around 2 or 3 seconds, and N was around 8 or so seconds.
There are a variety of reasons that many elevators do not work or appear to not work in the US.
• Some are programmed not to work during times that are normally high traffic to encourage fuller cars.
• Some have a delay. If the door was going to close in 5 seconds normally, and the close door button works but with a 3 second delay, it would only have an effect if you pushed it within the first 2 second after the door opened.
• Some are simply broken. A broken close door button does not put the elevator out of service so it can stay broken for a very long time.
• Some owners choose to have them disabled. Perhaps they have received complaints about too many obnoxious people closing the doors early. Perhaps they think that the law requires it (maybe local codes do in fact require it). Perhaps they think disabling it reduces wear on the doors (I've read somewhere that door problems are the most common cause of needing elevator repair).
I've seen quite a few articles that claim that the Americans with Disabilities Act (ADA) requires that close door buttons be disabled during normal operation.
I doubt this. None of the articles I've seen cited a specific section of the ADA, and I could not find any grepping through the text. Furthermore, the ADA was passed in 1990, but non-working close door buttons were widespread well before that. Here's a Straight Dope column on this from 1986, for example [1].
The most I found was something about there being a mandated minimum open time, during which the close door button would not be allowed to work.
[1] http://www.straightdope.com/columns/read/595/do-close-door-b...
Which still makes no sense: if a human being is pushing a close button, presumably he has a good reason for doing so.
I'm rather hopeful that the actual facts are that the ADA requires a minimum open time, and that a close button may shorten that time because it's an active human request.
"the customer should be able to use the product fully once they have experimented, tried, failed, corrected, and learned by mistake the user interface that we have"
Damn Poe's law strikes again
Now, you get a hamburger icon and there's not even an exit button.
Part of the joy of computing was figuring out what all those buttons and options did. VLC is one application that still has a decent settings selection and their advanced options is just about perfect. I don't even know what half those options are for - but I like it.
Please give me back my options to break stuff. I am not scared. Breaking stuff helps me learn. I don't even remember the last time I broke things bad enough to need a reformat. That's not for lack of trying, it's for lack of buttons. I'd like to kindly request you put those buttons back.
Seriously, discovering features and mashing buttons until you learn is one of the great joys of computing.
Technical people inherently know that there's very little they can do that's irreversible, and that they'll be able to figure out how to reverse even the craziest of breakage.
Non-technical people do not assume breakage is irreversible, and even when they do, they do not assume that they'll be able to unbreak it themselves. Finding someone to help is a nuisance and can be embarrassing.
It's not like I'm expecting a return of dip switches and multi-binder manuals. Just, maybe, stop designing for the lowest common denominator?
People aren't going to learn unless you give them a reason to. People aren't going to learn if they don't have to. Would you rather smarter users, or simplistic software that underperforms and offers only one output option?
I favor choice.
I do admit that it makes good financial choice to cater to the lowest common denominator, but even many of my beloved Linux apps are getting dumbed down. I haven't even had a kernel panic in years. Hell, I haven't even had to compile my own kernel in this whole decade. (I have, I just didn't need to.)
It's not about keeping it out of the hands of the less technical, it's about still keeping it educational for those of us who are. What kind of dystopia is it, when the preferences menu has but three options?
Instead of a stylus, maybe you should just give me a crayon!
Really, I think VLC has it right. Handbrake is pretty good. Gimp goes a bit overboard, but I can respect that. My VNC server? It's got like eight options, total. Torrent client? Maybe twice that many, spread over four panes. That's like putting four pieces of lettuce on four plates and telling me it's a salad!
Mobile apps? Some of them don't even have options! If there are no options, why use an app? Just use the web! Hell, they don't even have a close option, some of them. What if I want to close it and restart it at the default screen? Task manager or reboot, that's what. 'Snot like it has a discernable back button. No options to configure it, either.
I think people with mental handicaps should be allowed to use computers, just like everyone else. It doesn't mean you should design with them as your primary target audience.
I'm pretty sure it took more work to take the buttons out than it took to leave them in there. I can't even begin to count the number of updates that have removed options. What the hell was that? You worked harder to make the application do less. I don't even understand that mentality.
Sorry for the rant but this is a pet peeve. Imma start a Bring Back The Buttons campaign. It extends to other things, too. I noticed a friend's new television. Their remote had 3 buttons on it. It wasn't even broken, it came like that from the factory.
Having a very clear boundary between "safe for experimentation" and anything permanent/important is the most important part. People will learn to experiment if you explain that nothing will be saved until they press the visually distinct "Save Changes") button. When relevant, explain they can use the clearly marked "reload"/"reset" button to return to the original ("fixed") version, so they have a reason to feal safe experimenting.
"Magic"/"DWIM" interfaces and functionally overloaded UI features undermine confidence that experimenting is "safe", because they are hard to predict.
We'd have to go right back to OS design principles in the first place to teach people that computers are not terrifying behemoths that are about to fall over at any given second, and then maybe that would follow through into our apps - but as it stands, they come with the default expectation that anything they do might result in needing to call IT.
Funnily enough, ChromeOS gets that more-or-less right. There's barely anything you can do to a ChromeOS machine that makes it unusable, and nearly everything is ephemeral. Then you have the always-revertible settings in Google's web apps, and people love it.
Then, computing became useful, and had to be used by people who don't like to twiddle with settings. It seems to be the case that those are in the vast majority. Moreover, there is a vocal minority of people that tweak settings, break something, and then start complaining / requiring support.
The end result is that our preferences are no longer the majority and thus are no longer catered to.
Even Linux is impacted by this. I keep hearing complaints about flat design, I don't even know what that is. I just want my buttons back. New users don't actually have to push them. Just because a button exists doesn't mean Joe Sixpack has to push it.
Maybe if he pushes it enough times, people will stop fixing his computer and he will learn to fix it himself. Then, with time, he can learn to stop breaking it.
Not that long ago, I got some help to write some scripts to grab the entirety of the Ubuntu man pages and automatically convert them to PDF and provide an index for them.
When I posed my question, explaining where I was stuck and what my goal was, the first questions where, effectively, "Why would you want to do that? Nobody wants to do that!"
It's a horrible state of affairs.
I'm considering moving to GhostBSD. At least they still have buttons.
And this is great, simple UI that means you can use it without a manual. If we we're to liken a lot of "configurable" software to the toaster it would:
* A resistance range setting that defined the max and min resistance ranges of the internal heating element, implicitly measured in ohms.
* A resistance setting to defines the current resistance from 0 - 100% where the percentage set gets it's temperature from the range defined with the resistance range UI element.
* A timer setter that allows you to set the time-to-cook value via a ISO 8601 formatted duration.
etc.
When you design for the lowest common denominator, you get users that are the lowest common denominator.
I get it, it makes good financial sense. However, those of us with an IQ higher than room temperature are left out in the cold. You had those options in there - you took 'em out. Put 'em back.
Joe Sixpack will learn and improve. You'll get better and smarter users. You'll get users more confident and needing less support. Take an extra day and write good help documents, put the options back, and give ol' Joe a web form to query the FAQs.
Ol' Joe will figure it out. I did. Joe can figure it out too. We all did, back in the day.
If you don't give them incentive to learn, they're not going to learn. You're stuck with dumb users - forever. You don't want that, do you? Do you really want to have to keep telling Joe how to set up his email client? No? Well, give Joe incentive to learn how to set up his email client.
When Joe calls your helpdesk line, say, "Hey, Joe - did you read the manual?"
Give him a reason to mash those buttons until he becomes an expert button masher (also known as an admin). And, if you can't train Joe, you can use some pretty neat tools to lock his PC right down - and only let him do what you want him to do. If it's his cell phone, well - that's what he's got the restore option for. Ol' Joe will quickly learn to push buttons, fix his own problems, and actually understand what goes on inside that magic box - at least a little.
Seriously, we did this for decades. User friendly is good, but it's gone too far when there aren't even configuration options, a close button, a home button, or a help file.
DId y'all forget how to write help documents? There's some great examples out there. You can crib from those.
I'm not kidding about VLC pretty much having it perfect. Load up VLC and have a look in the options.
Open VLC > Click on Tools > Click on Preferences.
Once you're there, have a look around. That's pretty great, right? It's not too overwhelming, now is it? That's not the best part.
In the lower left, click on "All." It's right next to the Simple option - simple, like Ol' Joe. Click on that button and then take a peek at the options. It's a virtual cornucopia of button goodness. It has options for things they're probably just making up as they go along.
It's pretty much perfect. Even a plain text editor should have options like that. While not a plain text editor, LibraOffice is actually another example of a fine set of options. But, VLC gets it just about perfect.
Ol' Joe can still have the Simple options. Ol' Joe probably hasn't even got to touch them, as it comes with sensible defaults.
VLC could be the goal, not the Facebook app for Android.
Here's the problem though: many companies in our industry do want that, even if they don't admit it to themselves. That's how they make money.
A smart user will use their general-purpose computer and a suite of general-purpose software to solve their problems in a makeshift, but effective way. A smart user will not need to buy a service in a SaaS that's selling few textareas with a cloud sync. But a dumb user can be believed that "there's an app for that", and that things for which there is no app cannot be solved.
What's wrong with an options menu and then an advanced options menu?
People are down voting my comments that suggest keeping options in place in applications - on Hacker News. I don't even know what to think anymore. I miss my options menus. I miss the vast amounts of configuration choices.
What I really miss is learning what all those options did. There is still plenty to learn, I miss that. I miss tweaking, configuring, and getting things just right. I miss the little things you could do to tie in a couple of apps and make them do things they weren't designed for. I miss the finding the undocumented settings that you only found when you hand edited config files.
They inspired me to learn more. They kept things fresh. They made each person's install unique (which I admit is generally a bad idea in a corporate setting).
When you design for the lowest common denominator, you get uninteresting, uninspiring, uncreative, inexpressive, bland consistency. We've gone from a multitude of choices to bland bowls of oatmeal.
If need be, put the options behind an 'advanced options' radio button and emulate VLC. I'm not kidding when I point to VLC as being close to ideal.
And no, I am not a curmudgeon. Computers and applications weren't better back in the day. In fact, they largely sucked. That's not because they had options, however. That's because they were slow and had access to so much less information. The options menu had nothing to do with it.
I don't want to bring back old computers. I just want my options menu back, and populated with optional goodness.
Do you use Windows? I haven't used it in years. However, there used to be a program called x-teq setup. It is now defunct, but that might have been the greatest Windows program ever made. It had a horrible interface, a UX was not even thought of, the UI was probably concocted while drunk, and it was an absolute security nightmare. But, you could tweak most any part of your OS with it.
It's that sort of mentality that makes me want my options back.
Thing is, lots of people on HN have internalized the "dumb UX FTW" principle - which is entirely understandable from the business point of view, where you care primarily about your sales, not about the value your users derive from your product - and by criticizing this point of view, you're implicitly criticizing their jobs or products. Hence the downvotes.
(In particular, a lot of developers despise options, because they increase "costs of support" - i.e. there are many more things that can break when you start mindlessly piling up new features.)
But criticize this trend we must, and loudly, because at large it is circular reasoning. Users want dumb software because they choose it, and they choose it because that's all that is available to choose from.
Computers are a tool that could give unprecedenced powers to individuals. Powers to learn and solve their individual problems themselves. And the software market is seriously, and increasingly, underserving individuals. It is understandable - companies prefer you to pay them instead of solving your problems yourself. But "what sells best right-fucking-now" is not the same as "what's the right thing to do".
So, I mean everything I say.
I have moderated my own posts to fit site guidelines, but I say what I have to say, bugger the votes.
So...
I agree, computers are tools to empower individuals in ways they've never been able to achieve in all of prior history, at lest on a mass scale.
To do so, they need to be able to get maximum usage from their devices. They need control of their data and their systems. Sure, they might make a few bucks writing blog posts, but the real power is in creation and, doing so requires skill and options.
This dumbing down of devices is a disincentive to learn. Dumb devices beget dumb users. Dumb users don't create, they consume. Sure, some exceptions exist, but this is generally true.
Dumb users are subservient to dumb devices.
So, along with my selfish goal of wanting to have more control over my devices, I guess there's an altruistic reason.
Maybe it really is time for a Bring Back The Buttons campaign? I could probably write a few essays on the subject.
From the 90s until about the mid 2000s, kids to me, there was a whole generation that actually understood computers, beyond just being able to open Office. They could put them together, understood ECC and RAM, built their own cooling systems, programmed what they needed, and devoured open source like it was a new religion.
Then... Well, then came the smartphone. I don't even regularly use my smartphone. I probably should. Maybe it will help me understand the next generation's viewpoints?
I don't know... We did pretty well for a while. People were even educating themselves. They created new and wonderful things.
I think I'll try formalizing this stuff into an essay and linking to it in a few days. Right now, it's rambling.
It is something I've pondered for a while. There's more to ponder and try to make sense of. This is meandering a bit too far off topic for the thread. Bring back our options and presences. Bring back our documentation. Encourage, no demand, people learn. You have to learn to use every other tool, a computer is no different. And yes, yes it is a tool. Even the network is a tool, a tool to facilitate exchanging information.
Man, I so hate the idea of having to write software. I really hate programming. I'll have to come up with a more practical example than VLC.
--
> Then... Well, then came the smartphone. I don't even regularly use my smartphone. I probably should. Maybe it will help me understand the next generation's viewpoints?
It didn't help me. Anyway, if you'll get a smartphone, you'll learn that:
- it generally solves most of your needs for unsophisticated communication with people
- it sucks when you try to do anything creative with it
- it has abysmal interoperability between applications - and beyond that, it goes out of its way to hide the filesystem from you, and even the clipboard barely works
Both of that is because it's bound by the features of lowest-common-denominator applications written by competing vendors.
--
> I don't know... We did pretty well for a while. People were even educating themselves. They created new and wonderful things.
Of course they did. Because if you tell people that a) they can make things they want to make with a computer, but b) they have to spend a little time learning and figuring it out (and c), here are some resources to get you started), people will figure it out. Some of the complexity just is essential, you can't remove it without losing the capabilities of the tool.
> I think I'll try formalizing this stuff into an essay and linking to it in a few days. Right now, it's rambling.
> Man, I so hate the idea of having to write software. I really hate programming. I'll have to come up with a more practical example than VLC.
Please do write it down and share it. And don't worry about writing software (unless you just want to have your dream tools made ASAP) - just provide a clean and detailed description of what you seek. There's plenty of people here who like writing code, and will happily experiment with new paths.
Oh, and VLC is a fine example. It's a popular and powerful piece of software.
TL;DR: newish Androids sucks far less than previous/other types, even though they're constrained by the form factor.
That said, they have yet to take away unknown sources (and even seems to have refined it a bit with the latest version), so there is a small light at the end of the tunnel. But why oh why do they keep screwing with basic file management?!
Of course it requires a manual. You think it doesn't, probably because you saw your parents use it, or saw it used on TV (or because you're a technical person and figured it out yourself from first principles). Even such simple things are learned, and for some users, need to be explained. Hence appliances include manuals.
Also: while you know how to use a toaster, if you find yourself in front of an appliance the type of which you've never seen before, you will naturally reach for its manual (maybe after first trying to figure it out yourself). You will not run away screaming, you'll learn to use it, and you will not think it is a weird thing. Similarly, nobody bats an eye at the prospect of having to learn how to drive, or use power tools. I think the single biggest sin UX is doing is promoting the expectation that using software is not something that requires learning. We're now training people into thinking they should become experts in 5 seconds, whereas in every other area of life there is an expectation of learning.
And then some people confused "twiddling with settings" with "learning to use a tool", and the completely stupid notion of "fully useful from first 5 seconds of encountering" software came into being.
Then, stupid defaults were conflated with 'having settings at all' which made people not want any settings.
In many cases there is an inherent complexity to a product, and it warrants some learning curve. Removing the need for documentation often removes power and depth.
Funnily, now that many products are like this, the opposite trend is surfacing, and in some niches you have customers who love reading manuals. It becomes part of the user experience.
It doesn't remove the need to read docs, especially for people who are new to DAWs, but it does alleviate a lot of the intimidation factor and initial learning curve that can come with needing to find what you need to read in a manual for a complex piece of software.
(that's not a complaint)
A solution which is often asked for by advanced users is a toggle between simple and advanced UI, but this has fundamental problems (The following is inspired by the VLC preferences UI). First, It will be triggered by accident by users who definitely don't want it (or by advanced users sharing the account). How do you ensure they can get back to the simple UI? By definition they are now in a mode which is harder to navigate for a normal user. Second, how do advanced users without extensive knowledge of the internals of the software (non-developers, essentially) locate the controls they were used to from the simple UI? The advanced UI will look fundamentally different from the simple one, because cramming all the advanced features in between the simple ones would just look weird and hacky. Things might even be named differently in the advanced UI because there are technical terms for them which will be more familiar to advanced users. And how do advanced users know if there is even a 1-to-1 mapping (a simple "Dolby Surround" boolean setting vs an advanced "Force Detection of Dolby Surround" boolean setting and "Stereo audio output mode" which can be set to "Dolby Surround")? Third, given finite resources one of the interfaces is going to have more effort applied to it than the other one. How do you ensure that they both stay usable when most users will only ever use one of them?
> The easiest way to achieve that is simply to remove functionality
The easiest way, yes. I am reminded again of the point made by Dave Smith, one of the Xerox Star human factors designers, at the ‘Final Demo’¹: “Star had many fewer commands than today's systems, and it didn't do it by having fewer functions — it just had fewer commands.”PARC weren't trying to make things easy on themselves. Genericity is hard. Orthogonality is hard. Design is hard. (It's unfortunate that Steve Jobs either didn't understand what he saw, or didn't care, and popularized a Potemkin village imitation.)
¹ https://www.youtube.com/watch?v=_OwG_rQ_Hqw (The particular session starts around 54:30.)
Others have managed to touch on this topic in the thread, so I'll just say this: you don't expect people to be able to fully use a car without having to learn anything. You subject them to a training course. And this applies to pretty much any actual tool. You have to learn to use it effectively. "The only intuitive interface is the nipple, everything else is learned." You can embrace that and figure out how to efficiently teach your users, or you can forever be doomed to building toys that don't actually help anyone that much.
Consider a bad example: Blender. Even though I have used 3D graphics and CAD extensively I still always have to look things up in the Blender manual. Why? Because nearly every control is poorly labelled, there are no useful tooltips, and basically no hints in the UI at all. Take a look at this awful screenshot for example:
https://www.blender.org/wp-content/uploads/2017/08/Release_n...
What does "File Extensions" do? What about "Placeholders"? Why do none of the number inputs even have units?
Nobody is saying that users should have an intuitive understanding of what a B-frame is, but I shouldn't have to read the manual to find out whether the B-frame interval is specified in seconds or frames.
That's just blatantly false: https://i.imgur.com/MGrA4Ax.png Not only are there tooltips, the tooltips also document the python API.
> I shouldn't have to read the manual to find out whether the B-frame interval is specified in seconds or frames.
You mean Max B-Frames? Yes, you should know what B-Frames are and that's enough to understand what you can configure. If it said "Max Frames" would you ask yourself if it concerned frames or seconds?
Blender isn't an App that anyone should be able to use. It's a complex, specific tool with a lot of features. I've seen many hours of 3D software trainig for anything from Maya, 3DS, Zbrush to blender. Industry professionals usualy take a few courses and need time to adjust before switching software. Each tool has different workflows and only after ample training are you able to fully utilise its power. Blender is built to be very efficient while modelling, sculpting or animating with loads of shortcuts and modes to make these processes as fast as possible in the 3D viewport.
You're basically complainig that an airplane control panel is ugly and bad when you have no piloting training.
Bad? Not at all. UI designers try very hard to make them intuitive, and from what I hear are largely succeeding.
TBH, if I look at an aircraft cockpit (especially a modern one), I have little trouble orienting myself, or figuring out how to tell the plane to do what I want. However I can easily believe that a person not well acquainted with airplanes and their systems would be overwhelmed. However that's not bad UX, that's just exposing the airplane's complex systems.
I recently watched a few pilotseye.tv videos (the things people do for fun...), and observed a lot of very interesting details in the planes' UI that made a lot of sense, and underlined the attention to detail on the part of the UI designers.
Sauce: I'm an aeronautical engineer.
See. This is the problem. It's just an excuse. I'm not saying it is possible to make Blender so intuitive that my mum could use it, but you shouldn't start from "this is a complex app so we don't need to make it user friendly".
Ooo I just thought of an even better example - Kicad vs DesignSpark PCB. Both complex software, but one is about a million times more easy to use.
RE bad UX - I agree labels and tooltips are important. Even if I'm an experienced user, I do not remember everything, and in particular I would like to be always able to visually identify that number fields use the units that I think they use.
As for the good sides - Blender is the vim of 3D graphics. It allows you to be much more efficient - after you learn how to use it - compared to programs with simpler UI.
I generally summarize my point like this:
productivity
^ / tools you need to learn
| |
| /
| |
| /
| |
| /
| |
| /+
| /-
| /-- toys with dumb UI
| /-- /--------------------------------
| /---------------/------------
| /--- /------
|-- /---------
+----------------------------------------------------------------------->
timeNot even that, many many babies don't know how to do it at first: http://www.normalfed.com/help/babyget/
Then I guess god himself built the Excel pivot table UI, because I know I never read the documentation on pivot tables before diving in. I just picked up from somewhere that a problem I had might be solved with a pivot table, dug through the UI to find the ‘insert pivot table’ option, and followed the prompts, backtracking with ‘undo’ if things went wrong.
There is real power in interfaces where a user can, knowing that something is possible in the tool, figure out for themselves how to accomplish that goal. Yes, without having to read documentation or attend a training course.
I didn't say "no learning required" I said "no reading required"
But the example the author notes isn’t the worst. If killing the app refreshes, that’s okay.
The problem is a lot worse if the app syncs to disk.
All Apple apps have this issue. iCloud is nice when it works, but it’s infuriating when a photo or something doesn’t show up on your other device, and there is no way to force a sync.
Their refusal to give you FS or cache access is similarly infuriating; I stopped using my old 16GB purely because I couldn't selectively control what was stored on the phone and iCloud photos was too dumb to control its cache. I would have gigabytes of old photos downloaded to my phone until it was so full that apps would regularly crash! I had to regularly toggle iCloud photo storage and basically just wait until my iPhone had locally cached enough of my library that it was full and broken again... And, of couree because Apple thinks their software "just works" or whatever, I couldn't just hit a "clear cache" button or manually rm files from the cache (still a hack, but one that takes all of two seconds).
At the moment, I'm keeping myself somewhat satisfied by just using adobe creative cloud for photos I care about, but it's not an ideal solution. And I'm annoyed that Apple basically forced me to buy a new phone a year or two earlier than I wanted to by crippling my old one with broken software.
Isn't that basically their business model?
Obviously the best solution would be to make the syncing of this seamless, but I'd happily go for a system-wide sync button...
Starting with the blessed Mac Finder.
Last week I needed a recently added file from an SMB folder, Finder stubbornly refuses to update its view, reopening or reconnecting is no use, etc.
Hit the web, found that for many years now the answer to refresh is "Force quit/reload the Finder". Oh well, that works, how elegant ...
https://scholar.harvard.edu/waldo/publications/note-distribu...
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
This combination means that the same hard lessons have to be learned over and over and over...
I'm guilty of not testing this sort of thing thoroughly.
Not sure about the others.
The rule of thumb, I believe, should be this: whenever you're dealing with a shared resource which you do not own - like with files on disk, or data on the other side of the network - your application state is just a cache for that data, and you need to offer a way to manually force a refresh of the cache.
I wish devs would still test like that. Sure, your app works fine in downtown SF on the newest phone, but try using it in Nowherseville, TN, on a phone that is more than a couple years old. I bet a lot of user frustration comes from dealing with that.
What you should do instead is to present to the user that you are in an unsynchronized state. I always add an internal watchdog for cloud sync and if time to last update goes above X seconds, you pop up a notification bar with a loading spinner that says "disconnected" and there you can add your refresh-button and a tooltip suggesting to turn on wifi.
When downloading things, refresh is a quick hack, for uploading things the situation is worse, there you should absolutely not pretend that things are done when they are not. Some times i need to know that a file was uploaded 100% before i disconnect the network. Again, the solution is not to add a manual refresh button, here you should always show the sync-progress.
For example: Instagram does auto sync of new posts, but it also has a refresh functionality. So I never know if it is up to date and I must refresh. When you know about a manual refresh functionality the auto update is totally useles. You're never sure if the app tries to stay up to date or does only occasionally sync to show some (not the latest) updates.
Another example is google mail, it does auto sync pretty well and I always see the mails when they arrive. But the refresh buttons makes me suspicious if it's really up to date (in my experience it always is).
GMail does a good job of being up to date, except when switching networks or resuming from sleep. It'll certainly eventually sync properly, but that can take minutes, and whacking the Refresh button fixes that in seconds.
I've also found that Refresh will surface very-new mail sooner than just waiting. Whacking Refresh while waiting for an email verification or password reset always makes it appear faster than just waiting.
I feel the difference between a programmer/power user and a regular user, and something that we need to start explaining to regular users, is that UI is not the true state of things. What you see is not what is really there. What you see is a representation, that is usually manipulated incrementally. A refresh is a request to rebuild the representation anew, from the true state of things.
The invisible college built a solution called Statebus: https://stateb.us It's a backwards-compatible HTTP but with automatic synchronization. It eliminates these bugs.
I think this gesture eloquently addresses several issues at once. (1) The user is going to pull down on the main container to check for new items at the very top of the list, but (2) it may take a manual refresh to deliver these new items; refreshing the list when the user is attempting to pull the main container window beyond the top-most item allows the app to provide the newest content the moment the user is seeking it.
But when the gesture is used in different contexts, it is less likely to be discovered. For example most chat apps add new messages at the bottom, so the refresh gesture should be scrolling in the opposite direction. Additionally, I don't tend to scroll through my message history very often, so I'm unlikely to discover this. Fortunately, most chat apps tend to be quite good at loading new messages.
It gets worse when there's little reason to attempt scrolling past the boundaries. For example, it took me months to discover that Chrome on Android supports the gesture (before that, I opened the menu to refresh). That's because to scroll on a website, I just pull once and then let go. Inertial scrolling means that the motion will stop as soon as it hits the top of the page. Past that, there's a kind of resistance that needs to be overcome, which you won't do if you don't already know the gesture.
My point is, good interfaces shouldn't require the user to make accidental discoveries. There should be an obvious, labeled way to do it; if necessary, it can include a hint to use the less obvious but more convenient way next time.
Also, i have found that swipe to refresh on web browsers to be a mixed blessing. All too easy to trigger when all i want to do is to scroll to the top of the page.
"Scroll to top of screen" is now overloaded with "dump all user state".
The number of times this has occurred when I've been in the midst of changing that user state (say, editing in an on-page dialogue) is ... large. It is an infinity compared with the number of times I've wanted to pull-to-refresh (nil).
I recall when mobile browsers started adopting this, and how many times i would trigger it just because i wanted to make sure i was at the top of the page...
In much the same way that the capabilities and usage of today's technologies baffles people who didn't grow up with it, tomorrow all of us will be baffled by the number and magnitude of decisions that the average piece of software assumes its users will delegate to it, and the fact that no one will really be able to debug or diagnose exactly why it made the decisions it did. Zawinski's Law [1] will be modified to read "Every program attempts to expand until it can act as a personal assistant. Those programs which cannot so expand are replaced by ones which can."
The thick-client MS Outlook will let you know when you have new mail, but there's also a "send/receive" button that forces a sync with the server and lets you know the result of that action.
Take Youtube for example.
If i scroll down to read some comments (yeah i know, i live dangerously for some reason that escapes me) and want to go quickly back up to the video, the natural reflex for me is to hit the home key.
But for some loony toons reason Google had decided to hijack the home key to mean "rewind video the 0 and start playing"!
I can see some files on the web version of google drive that I uploaded last night, but on my other machine the Backup&Sync tool doesn't even bother downloading them.
Time to move to Dropbox I think...
It costs $30, and it's a one-time payment, no subscription.
I have been fighting weak wifi+Windows10 lately.
I try to connect, and Windows will make every appearance of connecting fine, but actually assign itself a magic IP.
And the only way to get it to budge is to open a CLI and type ipconfig /renew, as there is no GUI way to force Windows to renew its IP lease. disconnecting and reconnecting, or toggling the wifi radio off and on will only refresh the magic IP:
Btw, why does the web Gmail refresh button not actually load new emails unless I press it twice?
All of a sudden what used to be a simple transfer from tablet to PC was a nightmare.
This because while before the PC would read the SD card directly, with MTP it was mediated via a database within Android.
And that database easily got de-synced from the actual FS state if i used any kind of file manager on the tablet.
Effectively i had to dig up an app that was designed specifically to force the database to sync.
You hear that google? Using adb on the command line is easier than the interface you give your phone? How did you mess that one up?
/rant
Of course, it helps that the browsers all have builtin refresh buttons too.
There are two hard problems in computer science: cache invalidation, naming, and off-by-one errors.
Source: https://skeptics.stackexchange.com/questions/19836/has-phil-...
The problem is this happens too many times, even in cases when the customer doesn't have any idea how to fix the issue and what the issue really is.
Never seen an out-of-sync error message in any application except for multiplayer apps/games.
Vacuum tubes.
Maybe I'm alone, but I've more than once gotten my local copy in a state that seems to require me to blow it away and re-clone it to get it working again. Sometimes it seems to get hung up at a particular point in time and I can't get it to pull recent changes, even when I've tried to tell it to pull from the head.
But IMO this tracks back to the MPA vs. SPA problem. Do we actually need to be using a SPA/JS framework (Angular, React, etc) and what do we get in return which outweighs the wildly agreed increased development effort of SPAs?
I think the author is referring to mainly "wrapped" SPA web apps that sit inside native apps with a "web view" rendering the SPA (like the browser would). It's not just wrapped apps tho, many native apps have some kind of hybrid where you're using a library directly (React Native?.. dives for cover) which but a whole framework of abstractions on top of the native interfaces. With so many "layers" and all these things being new and vastly more complex than MPA web apps, the statistical likelihood of goofing things up is just very high.
Where are the days of old (what? 10 years?) where we got to the edge of MPAs (we didn't even call them MPAs then) and optimised the crap out of them making them fast, and simple and quick and a pleasant user experience? I think we come up with all sorts of poorly justified reasons to go to SPA/JS frameworks these days and the users are the ones who end up paying the price.
MPA: Multiple-Page Application
SPA: Single-Page Application
SPAs can have refresh / reload mechanisms, but not all do. Same for native / mobile apps, some have them and others don't.
Already did that twice today in Evernote.
It doesn't. You can have refresh buttons in SPAs that refresh correctly parts of their stores. You can have MPAs that incorrectly (or don't even try) invalidate local storage cache. You can have backends with bad cache invalidation. You can have SPAs that are also MPAs (nextjs+react, nuxtjs+vuejs, univeral angular, etc..).
Fact of life is, once your "page" needs more than a non-trivial amount of "GUI", solutions like react are far more maintainable, easier to develop, more portable, faster, and most importantly, build better user interfaces.
No need to blame SPAs using the 2012 concept of SPAs when the cause is clearly a rookie coder or a bad UX decision from upper management.
> Since it totally refuses to sync, I have to switch to the Android “recents” screen and kill it. When I re-open the app, it’s OK.
The root hash would be sent as part of each update, to validate that you have the right state. If it's different, a hard update isn't necessarily required - you can find missing items in log time.
In addition, for large states (e.g. say all cars in a region/partition for Uber), you can use merkle trees to partition and validate that the client has one area right, without downloading all the data.
There are many other approaches, but I think a merkle tree isn't a bad method for the use case of client state validation in the use cases I described.
What are your thoughts? How would you architect it?