This could be a copy-paste of rants I have written. I think marketing has ruined pretty much everything. Everything has a subscription now, and it's in the cloud.
My experience is that everything is slower than when I first started using computers as a child in the 90's, and it does it worse. You don't own anything anymore, upgrades routinely take away features, and nothing interfaces with anything else.
There are a lot of reasons why building an app on a web framework makes sense, but the fact that I routinely lose access to applications I've paid for because the company has gone out of business or stopped supporting them drives me insane. I can still install Excel 97 if I want to, but I have 0 confidence that anything I've bought from Google will work a year from now.
I mean, there is perceptible lag in character entry that never used to happen. Sure, my computer used to freeze inexplicably, but Atom crashes often enough that I don't consider that a win, and text has a noticeable delay before it appears on the screen when using Atom. Text entry is something I can implement flawlessly on a microcontroller and the majority of applications I use on a daily basis get it wrong.
You do, in fact, have a choice, you always did, everyone does. There are decent, completely offline solutions (Libreoffice vs GDocs), you can self-host a lot of things and do a private "cloud" on a Raspberry Pi or an old laptop (https://yunohost.org/#/ ; https://cloudron.io/ ; etc). The tradeoff is compatibility and not being trendy. However, that has always been a problem both the 80s and the 90s. Mac vs PC? Amiga vs anything?
A lot has changed since and a lot has become more comfortable. It slower, more complicated, much more annoying. But you do have the power to simply stop using whatever you dislike[1].
So: don't buy from google. Build you own cloud. If you don't like the application or if it's instable (atom), use something stable (vim?). It _will_ be uncomfortable, but it's there.
[1] I'm well aware the cost of, for example, refusing to use Facebook, but you still can refuse to use it, whereas life without WeChat in Asia is becoming near impossible.
EDIT: Sorry for possible misunderstandings, I mixed up 3 different topics in a way too short answer. My point is: there are alternatives, there are choices. You don't like the user interface of something, protest: use something else. There _are_ options, but they are not the most visible, not the most comfortable choices, and many of them will involve setting services up for yourself.
> There are decent, completely offline solutions (Libreoffice vs GDocs)
LibreOffice is slow. On a ~2010 business-class Dell laptop that still is in perfectly good physical condition, running Debian 9, with a handful of tabs in Firefox and a mosh running:
adamantoise:~ geofft$ time libreoffice --terminate_after_init
real 0m8.103s
user 0m1.696s
sys 0m0.520s
The rant here isn't about cloud vs. local, it's about performance and functionality. We had the cloud in the late 1980s, it was called dialing up to a mainframe, and it worked fine because software was designed to be fast in the presence of slow (by today's standards) connections. One of the examples of that -- library card catalogs running on amber-screen terminal -- was explicitly brought up in the rant.
> LibreOffice is slow. On a ~2010 business-class Dell laptop that still is in perfectly good physical condition, running Debian 9, with a handful of tabs in Firefox and a mosh running:
Libreoffice is monolithically designed, as shouldn't be representative of the generic performance of modern software.
The reason is that StarOffice was envisioned as desktop environment, therefore, all the components of the suite are loaded on the first startup.
$ libreoffice --writer &
$ time libreoffice --calc --terminate_after_init
real 0m0.104s
user 0m0.016s
sys 0m0.008s
If anything should be compared, then Microsoft Office should be used, as it always had a very fast startup (AFAIK, due to components preloading).
I think the article is very misguided; the problem is in the expectation that anything should be faster, even in contexts that are implicitly slower (networks, i.e. internet), or with features that will inevitably slow down the experience (e.g. browser plugins).
Using as reference the slowest software - Libreoffice, Atom, Firefox - is nothing else than cherry-picking.
In this perspective, a sibling article is correct - if you want faster alternatives, you have them.
re 1: Slow - compared to google docs? Are you serious?
EDIT: not startup time, who cares about startup time? When you load a few hundred pages doc, or a massive excel.
re 2: I only wanted to give examples, but you're right, my wording is off.
I wanted to say there are fast and good interfaces: there's vim for the terminal, there's Rainloop for webmail, miniflux for RSS reading - these are all keyboard-oriented ones, all working decently and as fast as they can. In case of web-connected ones, the speed of going back and forth is certainly an issue.
Local - as in not making connections on the network - in my opinion, will always have a speed advantage though.
> re 1: Slow - compared to google docs? Are you serious?
Slow compared to decent standards of what a word processor needs. For reference, WordPad perceptually opens instantly for me, and has felt like it opened instantly since Windows 95, I'm pretty sure. I am saying that both LibreOffice and Google Docs are examples of software that take way too long to do simple things because they're busy doing complicated things that I don't actually care for. (And arguably this isn't really their fault per se, they're both designed to compete with / follow the expectations set by Microsoft Office of what an office suite is, and those expectations are that all the complicated things are available).
> Local - as in not making connections on the network - in my opinion, will always have a speed advantage though.
Depends what you're doing with the network. I do just about all of my work in the terminal with a mosh connection to a cheap server a couple hundred miles away, and I never feel perceptual slowness from my machine not being local, unless I am literally in the subway or in an elevator. And I actually gain a lot of perceptual speed because I can close my laptop and switch to my phone instantly and see the exact screen where I was.
If you're streaming binaries from the network or trying to pump animations on a 2048-by-1536 true-color retina display, yes, remote is going to be slow. Half the tweetstorm's point is that you shouldn't be designing software to need that in the first place.
> EDIT: not startup time, who cares about startup time? When you load a few hundred pages doc, or a massive excel.
It was an example - the slowness (to me) is present for the entire interface. It was just easy to demonstrate. (Also in both LO and Google Docs I can type plain text into an existing document just fine.... I'm curious what you find slower in Google Docs than LO.)
My point is that this rant is not, as far as I can tell, a "local software good, cloud software bad" rant. There are reasons to believe that, e.g. debuggability and computing freedom, but UI speed is not one of them.
re 1: Slow - compared to google docs? Are you serious?
I can't speak for the poster above yours, but I would be serious. In my experience, on the startup time, google docs way out performs open office. It's open in single digit seconds, open office is 10s+
I still prefer offline software, but the bloat can be awful. At least web tech is designed with web browsing latency expectation. I find most desktop software these days has a much larger start and use latency by far.
Having a choice is not a thing for granted. You need to work for it. You need to maintain the right to it. Those who are not prepared, learn it, or live with whatever is provided by others.
Do you not like owning a car/tractor/printer running proprietary software that you're not permitted to modify? I guess you should have bought a 20 year old version and upgraded it yourself.
Do you want a choice of food that you trust won't make you sick? Then you probably should have worked for that lettuce from planting to harvest, not just complained about safety standards.
Total independence from the actions of others isn't impossible, but no one posting comments online is practicing it. And if "working for it" can include learning to use solutions other people have built, then it can also include writing this article on what's change and what's missing.
If you live in a society, talking about your preferences isn't an alternative to working for them, it's part of that work.
If you follow popular technology you get a slow stream of annoying technology thats predatory by nature. When I switched to the free software side, my experience sped up and I had finer control over everything. My files are mine and not a company's, non-free javascript is disabled so the web is faster, and my system is lightning fast since its devoid of windows telemetry. Encryption keys and offline password managers can be a hassle but the freedom overshadows the difficulty for me. Or maybe its stallman stockholm syndrome.
That's the survivor bias. There's plenty of things that you can no longer install and the things you can still install, it's mostly because there's someone that maintains their API and whatnot (thus, the company hasn't gone out of business or haven't decided not to maintains it). Look at games, GOG has an R&D department to make sure you can run the games on their platform.
I'm pretty sure there's a ton of people here that can talk about some old computer or VM that they have to keep up because of old legacy stuff.
> I mean, there is perceptible lag in character entry that never used to happen. Sure, my computer used to freeze inexplicably, but Atom crashes often enough that I don't consider that a win, and text has a noticeable delay before it appears on the screen when using Atom. Text entry is something I can implement flawlessly on a microcontroller and the majority of applications I use on a daily basis get it wrong.
Who forced you to use Atom? That's your decision to use something still heavily in development using some new technologies (not meant to be faster or more stable, just easier to develop into). It's like buying a bicycle and complaining it doesn't go as fast as the car you had before.
GOG only makes easy what the community and nerds have been doing for years. GOG made a business out of it because they pay people to "maintain" the "API". Their products are not under active maintenance nor development.
Now, if there WAS a company paying for all that maintenance it would be Microsoft, with their almost religious commitment to backwards compatibility.
> Their products are not under active maintenance nor development.
Isn't it the same? Someone that directly update the app to newer API or someone that update an API to make sure the older apps are still running is pretty much the same at the end. Someone has to do that work.
There's someone that pay for it, whether it's nerds by their time, or Microsoft by their backward compatibility support.
Even for Microsoft, at the end of the day, you pay that price through your next Windows license, and still, they may decide not to keep supporting some of it (16 bits programs are no longer supported over 64 bits for example).
It's not different from a subscription model, except that instead of paying a fortune to support most things (which may not include what you actually need), you pay only to keep support over the product you actually use and need.
I'm not saying subscription models or cloud application are amazing, but being able to keep running your old apps is not the norm and is mostly made possible because there's someone that pay for it for you. At least in a subscription model, that relation is pretty direct, you pay for the software to keep working, unlike hoping that Windows invest into that old techs to make sure they keep running.
"but being able to keep running your old apps is not the norm"
Only for the cloud cohort. Not all of us drink the kool-aid! Try living in a computing environment where the technology-rug isn't pulled out from under you every three months.
Both Windows and Linux have not had core changes to their API. The fundamentals of application programming haven't changed in decades. Why shouldn't we allow old apps to run?
I've got a good-sized collection of vintage hardware and software. Microsoft stops supporting something? All well, I've got my older versions still available. They don't get updates, but for the most part, I didn't expect them to when I bought them.
> you pay only to keep support over the product you actually use and need.
And you pay it over and over again. Until you don't need it (which might be because they removed some feature you were relying on, with no recourse).
> but being able to keep running your old apps is not the norm
Losing access to my old apps isn't the norm, unless I choose to let go of control over my own computer's software.
We've even managed to slow down things like Excel 97. I played with a 486 laptop recently, and was completely amazed at how fast things like Word felt (once they'd loaded off the ancient hard disk).
The most immediately notable part was the typing, which felt completely instantaneous. I haven't found out exactly why, but the switch from serial to USB keyboard interfaces (and the lag therein) as well as the various windowing pipeline "improvements" over the years seem to be in the mix.
Takeaway: today’s keyboards are slow. Even gaming keyboards marketed as fast are slow. There’s more latency just in today’s keyboards than the entire end-to-end latency in an Apple II system from 1977.
Old PS/2 keyboards are faster than USB because they were based on interrupts. That said, I think the cause underlying perceived low speed on modern platforms is more a bloat and inefficiency problem. Things are totally out of control. The PS/2 slight advantage over USB is an anecdote.
on PCs, keyboards were never "serial" as in "the serial port"(mice were), but they were always "serial" in the same way that the USB port is "serial". Perhaps it's better said that the switch from a special-purpose interface to USB is what introduced lag.
I know on microcontrollers, if you want to reduce jitter (by sometimes up to a magnitude), you disable USB. Ive noticed my interrupt loops on ARMs go way down when the micro doesn't have to service USB.
But then you have to use an STLink to upload programs.
I feel like this is the core of how "Open Software" is aiming to combat this. By removing the consumer-driven model away from software and putting users in closer touch with developers, we are supposedly developing tools together that better fit our needs. Though, OSS arguably is struggling to meet this theoretical ideal, especially with the current lack of support most OSS devs have.
My life improved considerably when I switched from Sublime to vim, Excel to VisiData, Word to LaTeX (though, I am unsure if LaTeX is completely OSS), etc. I invested the time in learning the language of the tool, but it pays off in droves.
There's no difference between OSS and proprietary software for the users, except price and the (most often theoretical) ability to modify the software and redistribute it.
Don't get me wrong: I use OSS wherever possible, contribute where I can, and love the freedom to tinker with the software's innards. But UI just isn't OSS' strong suit. Mainstream Linux desktops are no faster than MacOS, and quality as perceived by end users is far lower.
Some of that is due to missing hardware support, and some of it is a result of the OSS' "bazaar model" of development simply not being as good a fit for UIs as it is for CLI applications. But in any case, the forces at play in the market are the same for OSS and proprietary software.
The TeX sources are widely available and (infamously) well documented. The LaTeX macros are merely widely available. I forget what licence they're under, though.
> This could be a copy-paste of rants I have written. I think marketing has ruined pretty much everything. Everything has a subscription now, and it's in the cloud.
Well, shrink-wrapped software only needed to be purchased once to have something, and it was amenable to piracy. It also didn't let companies collect, expropriate, and sell off your private data. Hell, once upon a time, people even wanted to take EULA provisions to court as illegitimate, since you couldn't use a product you'd already paid for if you didn't "agree" to a post-purchase "contract".
Something had to be done to make profits sustainable!
I would blame Scrum and the culture of storyboards. Go and take a look at any storyboard. 99% of it is feature addition. Not speed improvement, not security. It is some "scrum master" who comes up and says 10% of our customers have said that feature X on our app would be awesome and based on this POOMA-ed projection we will have a 10% improvement in retention and 100% improvement in some other random statistic, completely ignoring the fact that you are negative impacting things like speed and responsiveness that the other 90% of the user base gives a crap about, which was not captured in this random survey of yours
> I think marketing has ruined pretty much everything.
Actually, in this case, it was technological advancement coupled with those companies' desire to make profits that 'ruined pretty much everything'. Marketing had nothing to do with it.
In fact, do us a favour and re-read your post, then tell us what parts were ruined by marketing?
The cloud is DRM. I think that and not scalability or anything else is the primary driver for most apps. It's a way of putting your code where users can't directly access it and charging a monthly fee.
I wonder how much of this is a result of UI designers deliberately putting tiny delays/animations into their UIs to make them more "usable"?
For example, it was a common piece of advice that if clicking a button opens up a dialog box, there should be a brief animation showing the box expanding from the direction of the button, so the user would associate the clicking of the button with the appearance of the box and understand where it came from. This does actually improve usability the first few times it happens, but over hundreds of iterations these tiny delays really slow down the overall experience of using the interface.
Just last week I discovered I could disable animations in Android through the hidden developer options. It's fabulous. The only initial quirk was no visual feedback when a picture is successfully taken, so it felt like i missed the button, but I've gotten used to it already.
There are also various visual feedback options, such as a CPU load indicator, or a debug renderer for screen touches which allows you to see if your touchscreen is misbehaving and how (happens to me when I plug my charger, for example).
> Just last week I discovered I could disable animations in Android through the hidden developer options. It's fabulous. The only initial quirk was no visual feedback when a picture is successfully taken, so it felt like i missed the button, but I've gotten used to it already.
You can also speed them up a bit. Makes the phone seem a lot snappier without breaking apps that seem to rely on animations for timing (I'm looking at you, messenger's "share" feature which doesn't have a send delay if you disable animations)
Another bonus is how much longer your battery lasts without animations. I'm pretty sure battery saver just turns off tactile response, and disables animations for the most part (in addition to changing the gps update speed if you are using location services)
Try setting just "Animator duration scale" to 0.5x while leaving the others off. This will fix the camera problem, as well as makes things like closing apps in the "recent" list less janky, and you still get the rest of the benefit.
It's a real pity that there isn't a .25x setting, or even a .125 setting; the .5x setting feels nice, but still a bit slow-ish. I understand that the intent here is to simulate slow phones (try using the phone with the 10x setting — it's horrid!), but it'd be nice to simulate a fast phone instead!
Even on the 0.5x setting things like the refresh pinwheel spin a little too fast, so 0.25x might be a bit much. It just controls too many different animations.
Completely disabling animations would break many apps, because a lot is going on in completion blocks of animations. Setting animation durations to a very low value would work though (that’s also what you have to do for UI tests).
A lot. Just take a look at the desktop switching animation in OS X that's been there now for years. I bring that up anytime anyone tries to suggest Apple has decent design sense. No sane UI designer would put something like that in without the possibility of disabling it (like their other shitty animations). To be clear, any UI designer who hasn't understood the absolute fact that after a hundred or a thousand times, any animation becomes despised by a large fraction of one's user base shouldn't be working in this field. A lot of these unqualified people also apparently make a lot of videogames with un-skippable cut scenes. Same idea. Same stupidity and lack of any forethought whatsoever about the user's experience. It's almost like they're making this software with only the manufacturer's goals of looking 'shiny', 'sleek', or whatever dumb adjective of the day people who don't understand tech use to describe it. Oh, wait a second ...
Few years back when I had to use OSX I tried to use native workspaces. The switch workspaces animation was already too long for me the first time. In Windows there are (were?) at least all those registry edits that one can do to do whatever one pleases. Also Windows has the adjust all visual effects for best performance setting. But I couldn't find anything for OSX.
An example of the way I use workspaces:
- one workspace for terminal, browser with documentation and some text editor
- second workspace for a full-blown IDE, another browser window with documentation and the developed application
It's funny that there are easy solutions to the cut scene problem. If user skips the cut scene there could be a little message that if you press some key the cut scene will replay. And/or give the list of all cut scenes to the point somewhere in the menu. But most of the time cut scenes are there to bring the cinematic experience and are easy and lazy thing to do...
That's a huge frustration with current web pages for me, and for iOS. Animations that stall interaction rather then enable it do exactly the opposite funtction. And if you're ever in a situation where interactions get chained from user requests, like the bug in the iOS calculator, you're gone way off the path on your UI
That had zero effect on the interaction-halting animations for me.
I'm not opposed to animation, I'm opposed to animation that makes the phone unresponsive and not listen to input, or delays the display of information for more than 200-300ms. Unfortunately the "Reduce Motion" only seems to be for some very minor things.
>I wonder how much of this is a result of UI designers deliberately putting tiny delays/animations into their UIs to make them more "usable"?
I disable most if not all of the animations on my android phone and windows desktops for that very reason. The animations make for great tech demos but also makes everything feel so much slower when trying to get things done.
Maybe those animations could be sped up with continued use. Then new users get the visual connection between their actions and the response, while experienced users don't have to wait as long for the animation to play.
No other UI infuriates me more than the McDonalds ordering UI at their locations. Everything is all over the place and the animations make it 100x slower.
I think animations, as most program them, slow down the UI exactly as you say.
But when their timing is tight, and the whole thing happens in under, say, half a second, you get the benefits of that context association and it still feels really cool and high-tech. People jsut set their animations too slow. (Seriously, nothing should ever take longer than 500ms)
I don't have a link, but in referencing interactivity tests for some remote software development I did some years back, the maximum time between pressing a button and perceiving its effect to be considered "instant" is around 200ms. You don't want to go slower than that if you want it to "feel" fast & responsive.
You're talking about Nielsen thresholds, and the limit for "instantaneous" is actually ~100ms.[0] Anything slower is considered to have taken some time.
Now, if that wasn't depressing enough - the Nielsen research is from early 90's. In the intervening 25 years, the users have certainly not become any less impatient.
People jsut set their animations too slow. (Seriously, nothing should ever take longer than 500ms)
They could start with 500ms and subtract 100ms from each UI activity after each time it is used until the delay is 0ms.
The user would learn the interactions on the screen first and then not be bothered by the animations later. As a bonus the user might actually thing the program "speeded up after a 'break-in' period".
Now that's an awesome idea! It'd be fine to actually just store that setting in memory, and reset with every restart: I wouldn't mind a half-second delay on my first window zoom after restart if I knew that it'd drop down to zero four zooms later.
The front end developer at one of the companies I was working for nearly fainted when I told him I like Craigslist's web interface. The only criticism he could muster was "But it looks like the 90s". And then he proceeded to tell me off "because you don't want to learn how to use a new interface". Of course I don't want to, it is a skill with zero transferability. Learning how to be productive with an interface that only works with 'a' given app, for 'a' duration of six months until some bozo changes the whole UI, because some focus group decided that "it would look so pretty if ..." (and that is the best case scenario, mostly it is because some UI/UX guy was inspired while sacrificing chickens to a graven image of Steve Jobs) is bunk. The two most hated things that came out of Redmond in the last 20 years were the 07 rejig of the Office UI (so you had muscle memoried a bunch of key strokes that made you super productive, well the F U buddy, we are going with this weird ribbon thingie for no discernable reason - fixed that by recording a bunch of macros that did what Office 03 did) and the Win 8 UI. I mean which diseased mind thought that it would be a good idea? And if that was not retarded enough, to force it on server users.
Craigslist has an amazing interface. It's so easy to use. It's ugly, but who cares! I don't care if it's pretty. It does exactly what I want. There was a great article on this a few years ago that I think is perfect: https://m.signalvnoise.com/why-the-drudge-report-is-one-of-t...
Craigslist UI/UX is great. The problem is that simple/super clean interfaces don't require designers. So pretty much every designer will be against it out of principal.
The Office ribbon was/is far superior to the original, flat UI for novice and intermediate users. By flat, I don't mean aesthetics but rather the layout. Every menu option and button had the same visual importance of every other button/option which makes it difficult for novice and intermediate users to find the right one. It was fine for power users because they will put in the effort to learn the interface no matter how crappy it actually is. And power users usually get upset when the interface changes because they now have to relearn it. But that doesn't mean it was a bad change in absolute terms, it is a lot better for non-power users which are the vast majority of users.
In the name of usability, we have practically neutered these computing machines. I think optimizing for user experience is partly to blame for this. You don't want users to have a confusing experience the first time they use the application, and you want the application to look good and be inviting. But that may be at cross purposes with making applications that allow open-ended exploration. Exploration implies that the user is driving the process, which suggests that the UI is not actively trying to constrain them to the usage patterns it is designed for.
I think pretty much everything in computing is like this. By setting our sights on enabling users rather than training operators, we have not only limited what they are able to do, we have actually turned ourselves into users, and we're basically unable to program without the help of frameworks, libraries and Stack Overflow.
> In the name of usability, we have practically neutered these computing machines.
Except usability is getting worse too. There is now less and less content on the average screen and more and more whitespace and "design chrome". Buttons no longer look like buttons, hamburger menus are legion, and many new features are found behind undiscoverable gestures that must be mastered.
I have a theory that by optimizing for the UI/UX of a First time user, things have gotten worse for the power user. In the past when most of our apps were desktop apps, there was a hidden assumption that the user would be using the apps for years and therefore had the time to build up muscle memory, currently when bulk of the apps on App Store are not downloaded and those that are, are barely opened twice, it makes sense to optimize to make the whole thing easy for the FT User. That by definition makes it harder for the power user. Notice that the really responsive websites are ones that cater to a group of people who by definition are more likely to be power users: HN, Github etc
There is a big dose of fashion and fad-following in usability. The things you mention are manifestations of poor decisions made in the name of usability, but actually in the interest of being pretty.
I think even making the right decisions in terms of usability, tethered to a few short-sighted user stories, will result in this situation. Usability should be in service of a higher purpose, which should be enabling the user to understand how to use something powerful and flexible that does not constrain them only to what is envisioned by the developer or the UI architect. That's what has happened here with Maps. You can perform User Story #1 or #2 with zero friction. But there is no way to do what @gravislizard wants to do, which wasn't anticipated by Google or specifically designed for.
Not only is there a lot of fashion and fad-following, but there is a distinct lack of measurement and metrics. You want this animation or to change the color on this control? Fine--show me the empirical data that demonstrates that it improves usability or any of our KPIs. None of this, "I'm an artist and I subjectively feel this will be good for users." That's total BS. Show me the measurement that justifies your design request, or let's A/B test it.
Did we forget how Emacs used to mean "Eight Megabytes And Constantly Swapping?"
Saying that as an Emacs User for almost 20 years now. Even today there are things that can bring Emacs crawling to its knees. The moment you start adding auto-complete to a big project, or if you have your files hosted in some NFS server, you're SOL.
The autocomplete is somewhat easy to fix in principal. Just offload to a daemon for the autocompletes, for example.
No, I haven't bothered with it. :( I did setup GLOBAL, which is quite nice. Though, many languages nowdays would benefit greatly from a presentation compiler. Which seems silly, at the extreme. It isn't like projects have gotten more complicated in scope. They have ballooned in implementation complexity, though. :(
But vim/emacs are ancient, and even Blender is from the nineties. I would say the situation is pretty bleak if we need to rely forever on these ancient beasts because we can't make good software anymore.
Ancient,yes. Still actively developed and maintained. Maybe if contributing into projects was more of a thing, then trying to reinvent, we had better sofware.
I simply cannot agree with the take that making things easier to use "neuters" them. Enabling people to actually use these things makes them more powerful, not less.
I think far too often, people get caught up with the false machismo of, "This is hard to use, yet I can use it, so I'm a badass and you're not."
I agree with you about false machismo. I'm trying not to say that hard-to-use tools are essentially good. I am saying that some essentially good tools are not very new-user-friendly, and that worrying excessively about the new-user experience has been detrimental overall.
One reason for that is the "new user experience" for a more powerful system will imply learning some things that are not directly relevant to whatever problem you are trying to solve. Excel worksheets, layers in Illustrator, "command mode" in vi and Blender, etc., are more like gas/brake pedals than they are like "do you want directions to this destination?" I don't see how you can avoid thrusting some learning on new users of a powerful system. Powerful systems are going to have powerful metaphors that are probably not totally intuitive at first.
You can do more stuff with Illustrator than Omnigraffle. It's a more powerful tool. That brings with it a longer or steeper learning curve. But, if you just want to make a few charts, Omnigraffle is easier to use.
I do feel that, over time, we have become very gun-shy about making complex applications that have richer models like this though, preferring to make applications with simpler UX that aim directly at smaller problems. And I think this is partly because UX is more straightforward for smaller problems.
But that depends on easier for whom; the issue is that is a system is very easy for beginners it will be crap as an expert and vice versa. This is the reason a lot of applications used to have a beginner/expert mode switch. When I use a mobile app, it is usually beginner only, so every time I have to go through the same steps and explanation wizards. I don't want that; most of these things, for experts, would be one form while for beginners they are 20+ pages. Literally.
Error messages are very generic and are passed immediately to support (more work, more time for an expert who probably would understand the real error).
Nothing wrong with that but it is not easier to use for me once I am an expert; it is harder and more annoying.
Last year, in a fit of nostalgia I finally bought an Apple IIe, a system I had wanted 30 years ago, at a garage sale. Somehow in moving it back to my house, I dislodged the floppy controller card, leaving the system to boot from ROM. I turned it on, it beeped, and there was the prompt. I perceived it as instantaneous. I know that from that point I could have written a BASIC program and saved it to a cassette tape. The anecdote falls apart once you actually start trying to boot ProDOS from disk and have to rely on the something besides solid state.
This experience got me thinking. What has changed in the meantime? Computers have become communication devices and communications devices have become computers (though even this ancient Apple came to me with a modem installed). Developer time has outstripped hardware costs, and somehow an hour of developer time is worth the same as wasting a million hours of the users' time (1 million users x 1 hour or whatever formula you wish).
I think we all recognize this problem, and it's already too expensive to fix. The hardware and software space are too federated, too balkanized, too complicated to ever integrate a system into a cohesive whole in the way the Apple II was.
> Developer time has outstripped hardware costs, and somehow an hour of developer time is worth the same as wasting a million hours of the users' time
Key point here. It's hard to get the biz guys and product managers to agree with spending developer hours on performance improvements, because it's hard to measure the effect it has on business metrics. Does making your application take 750ms to launch rather than 8 seconds really bring in more sales? Who knows? Nobody tries to measure it either, so we'll never fix the problem.
Feature cram, on the other hand, is easier to justify, which is why every application eventually ends up with a plug-in interface, theme-able, skin-able, able to read E-mail, and able to interact with Facebook and Twitter.
And I'm not even talking specifically about application performance, though what you're saying is still absolutely spot on. Think of all the time wasted because of poor, or incomplete documentation. An I sympathize with anyone writing documentation. We're definitely still in the era of move fast and break things.
These costs which accrue to everyone because no one can afford to take it on themselves, I would call externalities in the same sense we do when talking about pollution.
The core point of the entire thread can be summed up by one of the tweets; "I believe well designed keyboard interfaces and well designed GUI interfaces have exactly the same learning curve."
I agree with this. A properly and well designed keyboard interface is faster than any mouse. On the other hand, a properly designed mouse interface can be fast too. Both need to be applied when it makes sense.
I can also resonate with the GMaps example; people find it rather ridiculous that I prefer to use pen and map to plan routes but GMaps simply does not cover the complex demands of holiday routes with family.
IMO Google Maps became completely awful when they made that new version of it, and they've been doing everything in their power to continue making it worse. Sure the scrolling is a lot smoother, but it's missing just a ton of features that the old version had. Plus the problems mentioned in the tweet storm, everything disappearing as soon as you change one item. PLUS that stupid side-bar that takes up half the screen now.
Edit: Here's another good one I just ran into -- I can't sign out of just one Gmail account. I have to sign out of all my Gmail accounts, and sign back into the ones I didn't intend to sign out of.
I'm not really sure how it works under the hood, not being terribly familiar with how these login systems work, but you can basically (in your browser) click "add an account" and it will open a new tab and you can sign into the account. So right now I have 3 tabs open for gmail with 3 different accounts.
> Edit: Here's another good one I just ran into -- I can't sign out of just one Gmail account. I have to sign out of all my Gmail accounts, and sign back into the ones I didn't intend to sign out of.
This seems like it is a shitty behavior inherent with OAuth. I have half a dozen Microsoft accounts for various things, and you just can't sign out of one and sign into another, unlinked account - things go all sideways and the auth providers that are trying to read your cookies get really confused and go into 401 redirect loops. It's better to burn it down and open a new set of incognito tabs instead.
Given the speed of modern computers, I'm fascinated by the fact that so many processes complete in human-scale time (seconds-minutes), rather than milliseconds or years+, depending on problem complexity. If times for compute tasks have some power law distribution (a big if...), I'd expect a very small part of that distribution to overlap with the 'seconds' range.
Then again, computers do so many things in the millisecond range and faster that maybe what we observe IS only a small fraction of the total.
It's a relief to do a bit of Go from time to time, render a complete html template in 40 ms (with almost 2 MB of JSON data) instead of spending forever figuring out the JS framework du jour to do the same thing, only with it feeling a lot more involved, heavyweight, and slow - even if said framework claims to be faster than all the other JS frameworks.
I think I want to do back-end or terminal-based interfaces again. Native interfaces. Mmmmm
If you decide to work on native GUIs, please don't create your own toolkit on the assumption that you can do better than the OS. You'll almost certainly break at least one thing: accessibility for blind people.
This has nothing to do with Go and a lot to do with choosing the right tool for the job. Maybe Go is the best tool for you in this job, but a given js framework can serve someone else just as well if it is in their expertise area. Don't confuse your expertise with language/ecosystem pros and cons.
This has nothing to do with choosing the right tool for the job, but with performance, which this discussion is about. Practically all JS frameworks, having multiple levels of (near-inscrutable) abstractions naturally degrade the performance and certainly contribute to the trend the submitted twitter thread is talking about.
I've had a similar experience on a current project.
Even after disabling any and all caching and minification (read: basically parsing all templates per request, a bit like PHP), the entire render process take less than 20ms of time to the point that I've simply left out caching during some production runs.
I also keep the interface free of any expensive rendering precisely because I don't really need all of the niceties of JS frameworks.
Surely, the page could be more fancy but vanilla HTML5/CSS3/JS can do the job too. (And document.querySelector has replaced jQuery for me)
It's pretty much an availability heuristic / complexity (or cost) constraint.
If the operation cannot be done quickly -- in a few seconds at most for reasonably interactive work, in a few minutes to, perhaps, a few days for batch -- then it's very, very very rarely done.
It it occurs in less than about 1/10 second, there's not much incentive to try to speed it up, and inefficiencies that bump process time up to even a few seconds tend to creep in. That despite the fact that there are psychologically and outcomes-measurable differences between interfaces with even 1/10s vs. 1/1000s delays or responses.
The Jevons Paradox plays into this, balancing against Gresham's. Stuff that's cheap (clock time) happens, stuff that's non-discernable (under perceptible / outcomes limits) tends not to get constrained.
I think the opposite direction is actually more telling. Developers tolerate bloat and BS up to the level of seconds.
So there is plenty of computation being done that only requires milli or microseconds, but due to development practices now stretches just out into the annoying time frame.
(Prime example: the growth of web pages to match increases in processing, RAM, and internet speeds, means that the web is actually slower to use these days.)
When the web was young and most people were on dialup, having access to a T1 meant that everything happened nearly instantaneously. All the sites were optimized for dialup levels of complexity. Now that everyone has broadband there is no equivalent. The slowness is either because the page is so heavyweight in terms of memory or processing power (note that more money does not buy much single-threaded performance), or because it's making so many network requests that everyone faces at a similar latency.
Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again.
> Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again.
Until you install an adblocker and disable javascript. An enormous amount of modern-web overhead is adtech and user
tracking cancer.
If you don't believe me, install privacy badger/ghostery and ublock origin, visit any popular news/entertainment website, and look at the number of blocked elements/requests as you load a few articles. All of those take time and suck up resources.
I've experienced this. My first computer managed about 100 flop/s, or 3 Gflop/year. A modern PC can do that year's work in a millisecond! Yet when my current computer struggles to display a web page there isn't much interesting computation going on.
We're usually not computationally bound. Often its disk or network I/O and that basically means tasks are content bound. We tune for maximum content in the acceptable human scale time. The moment we take less than a second to load something it means we can find more things to load.
I think it's mostly a cognitive bias, we don't even notice processes that take milliseconds, and we either optimise or simplify (approximate) problems that would have taken years to make solutions more practical.
I kinda feel that UI developers should work with crappy, old PCs. Then they could optimize to the point where things are barely usable to them, but then they'd be snappy for everyone else.
Luckily Google Chrome has added device emulation recently for slower devices and network conditions. Hopefully tooling like that will make it in many developers Workflows.
No? Getting on a BBS in 1983 at 300 baud means text files "downloaded" at the same speed you can read. Word processors were crazy painful to use, and incredibly slow. A text editor was just a line-by-line replacement. My TRS-80 would slow to a crawl even making the most basic (ha!) of programs.
Over the years, I've often thought about why computers never seem to get faster - mostly it is because people have a tolerance for response speeds, and that is unchanging. So software sits somewhere inside that tolerance range, because why be ultra fast when most people don't really care that much?
Yeah. For me in 1983 loading something meant 5 mins waiting for the cassette to play through. Switching to a different program meant repeating the process again.
One of the computers I had was cassette tape based, and the tape "reader" broke. I was rather shocked to find I could use my parents cassette player and connect its output to my computer, and it would (generally) read tapes just fine. As a bonus, I figured out how to have the speakers on the tape player on at the same time so I could listen to my programs being read in :D
The author went back a tad far, but not too much. The Amiga came out in 1985 and the Apple IIGS in 1986. The user experience of those machines would be more comparable a modern PC with a thousand times the clock speed and memory
Sure, some small amount of people care, definitely. And there are options for them. And everyone would like it if things were faster, but they just don't care enough to put their money towards a fast, but less feature-filled, option.
Plenty of UX research confirms what I have stated. Why does the average webpage take N seconds to load, with a standard deviation of D? Because that's the range most people are ok with it and going faster has rapid diminishing returns, while going slower lets you get away with a lot of inefficiencies that results in reduced cost.
In reality, so many people have a problem with it that they are actively interfering with the code of the webpages to the point of endangering the business model of much of the web.
It's a tragedy of the commons. It's very rare for one piece of software to be solely responsible for slowness, but each individual piece contributes just ever so slightly.
I happen to know quite a bit about front-end technologies, so I'll speak to those. Bootstrap is around 100 kilobytes. One hundred thousand bytes - after gzip and minification. By itself, is it slow? Not very. Bootstrap fans will point you to endless benchmarks and tests that show its impact on performance. Same with React: one hundred and forty five thousand bytes, after gzip and minification [0]. According to React fans, React is blazing fast!
But development happens, so you throw in a few hip libraries and frameworks and suddenly Slack takes one billion bytes of RAM. Whoops. "But it's not React's fault!" Sure it's not. If React is the only bloated thing on your site, it will work great. But chances are that if you've got React, you've also got Bootstrap, and some visualization things, and some code from Stackoverflow that iterates over your DOM in O(n!^n!). And all of that is how things get slow.
Now, I might be a bit biased, because I spent years of my life working on a CSS framework 100x smaller than Bootstrap, but I think that if everyone spent time optimizing the size of things to be 100x faster we could get back to snappy UIs. Yes, it would be hard, and yes, it would require compromises, but the result just _feels_ good. There's something about a webpage loading in 250ms, or a button reacting as soon as you tap it, that just feels nice. Maybe it means not using React; maybe it means you don't use as many nice-to-have frameworks, but I think it's an achievable goal.
[0] React fans will point out that if you don't need to interact with the DOM, this gets smaller. Yes, this is true, but obviously for most webpages you kind of need DOM interactions.
Sure but tbf, we didn’t even have gpus in 1983, we had text and ascii, and a terminal. And a math coprocessor if you were lucky. And roads, and the aqueduct. And sewers. And a VT100
I've written many sites with React, Bootstrap, and a dozen or three other third party dependencies, but I've never run into a case of a button not responding when clicked or things taking a noticeably long time to load (assuming that the server processing or sheer size of the payload over the network isn't the cause).
I think a lot of it boils down to "don't do work you don't have to." But there's nothing about a framework that causes -- or saves you -- from that.
Great work on the sites you've made! Unfortunately, most of the time when I see a simple webpage not responding or lagging heavily, it's made with React/Bootstrap.
It's particularly tragic when the page is only text and images.
There was one I helped suggest fixes for on StackOverflow a while back. The program searched DOM nodes, found its target, split the node, inserted the two new nodes, and continued searching in the new node it had just inserted.
The result of this was truly horrific performance. If one node contained thousands of matches, the repeated node removal, copying, inserting, repeat, took more than 30 seconds. 30 seconds on a 4 GHz machine.
This! I once took over programming a point of sale system that our (internal to the company) users were complaining about. Turns out there was no concept of tab sequence, you had to use the mouse for everything. I asked the previous programmer to show me how to use the form he created, and he started typing a phone number using the top row of the keyboard instead of the numpad. But hey, it had lots of javascript!
To be fair, I only started using the numpad after I had a temp job in data entry. I hate laptops that don't have them now, but seeing as a lot of laptops cut them off, most people can't think num pads are that important.
Not paying attention to tab order in an enterprise app is a cardinal sin though.
> and he started typing a phone number using the top row of the keyboard instead of the numpad
As I'd expect any good programmer to...? As a 100+ wpm touch typist (including symbols + numbers) and former finance professional, I use the top row of the keyboard for numbers.
How is having 8 fingers available that don't have to move much going to be slower than using three that have to move up and down?
I get the point that the programmer wasn't behaving like the users; that's a good critique, but I'm picking up the vibe from this comment that you think the numpad is inherently better for that sort of thing? No way...
Edit: huh, seeing the chain of comments here, I guess I'm in the minority? I don't see how someone can consider them a touch typist (type quickly without looking at the keyboard) and not be able to reach and use numbers and symbols, but maybe a lot of folks here are like that? How do you program with numbers, and ampersands, and parentheses, and asterisks and the equal sign and underscores and all that, having to look down at the keyboard???
It just seems obvious to me that a skilled typist would be much faster using the top numbers than the numpad.
For those of us that have been fortunate enough to avoid having a job that involved an adding machine or cash register the number pad is an awkward AF to use. Conversely the top keyboard row is in range for touch typing.
I've avoided that job, but back when I still had a keyboard with a numpad I'd use that if I had to fill in numbers repeatedly. I can't touch type numbers accurately, it's just a bit out of reach.
I dunno, I've used the number pad by default since I was a little cutter begging to sneak into my mom's classroom and play on the Apple II that was in there. I might be a weird one; I can't switch myself over to using WASD controls in video games either; I've got to use the arrow keys, and then hope that I can bind the other important commands to keys in that vicinity.
I've always found it easier to type long strings of numbers on the number pad. I don't know why, it's not as though I ever deliberately trained myself to use it, but for me the number pad is much faster than using the top row.
Less ambiguity (three vertical rows, no horizontal movement), and the most-frequently entered keys (1, 2, 0) are not at extreme and hard-to-assess ends of the movement range.
Everything is much closer together, you don't have to move your hand only your fingers. It is clearly the better input device for pure digit sequences.
Not for left handed people. My primary hand is better/closer to the top row. My non-primary handle struggles with the keypad, especially if I don't use it very often - which I don't.
Worse, if you're on a laptop a lot then this habit is kicked out the door. Enabling a numpad on the keyboard is less efficient than just using the top row.
I'm left handed; the numpad is freakin' awesome for number entry. Back when I still played games like Descent and WoW, it was also very efficient to setup the mouse for my left hand and leave my right hand on the number pad. Aim and fire with mouse, maneuver with numpad (in Descent), or action bar items on numpad (in WoW).
I think that using phones trains the muscle memory for the number pad (although upside down). I have found the same thing though, where I instinctively can use the num pad much faster than I should be able to, with relation to the amount of time I use it.
I don't get your point about typing phone numbers. When I was being taught to touch-type in first and second grade, my teachers told me that I should type on the top row, not the numeric keypad. Not sure why. Maybe because it takes less time to move to the top row and back? Anyway, to me, typing numbers on the top row is not an obvious problem.
I mentioned that because I thought it showed how he'd never really watched one of the users in their job- once you get used to the numpad it's a lot faster. You can type in a long number very quickly without taking your eyes off the screen.
The numpad is a considerably faster input method, and it can be performed one handed. For a point of sale system, this is critical: the clerk can juggle an item while typing the phone number (or price, or whatever)
For a POS system input is probably all numbers- look up customer by phone, make choices from a menu, enter quantities. Letters are for new customers and special instructions.
I worked at a print shop that switched from DOS to Windows for it's POS software, it was an order of magnitude slower. At least we could play solitaire though.
Because most accountant and office types will use the numeric keypad and go blazing fast. That’s probably one reasons for the complaints. God help any PC tech who screws up their settings and doesn’t enable num-lock at boot.
> Maybe because it takes less time to move to the top row and back?
Presumably this is it. I find typing on numpad is much faster and simpler, but 1) laptops typically don't have one and 2) on normal keyboards it takes my hands away from the main keyboard. Then I switched to a Kinesis Advantage2 and now the numpad is integrated into the main keyboard, using a foot pedal to toggle between main keys and integrated keys.
It depends on the length of the number you're typing and the context.
In PoS, you're not likely to be typing many letters most of the time, so left hand for function keys, right hand for numbers is pretty good. You can move your hands if you move to a search.
When most of the stuff that you type are numbers then numpad makes more sense than top row (also, many non-english keyboard layouts have numbers in top row shifted).
For POS and similar applications it actually makes sense to design the UI such that it can be used only with numpad, for example by using +,-,*,/ as function keys for common operations.
The web is hundreds of times more feature-rich than 10 years ago too though. But, sites like HN are some of the few that are still built like they were 10 years ago. The rest all adds rich JS frameworks (for supposed faster interaction after the first load), a few billion social links, ads, cookie banners, "sign up for our newsletter" or "pay our subscription pls" popups when you first land on them, rich fonts, animations, images, etc.
I mean it's a lot nicer if you look at it from a distance after it's loaded, but it's not as snappy as it used to be.
I agree modern websites look a lot nicer... Or do they?
They all look the same: big images, not much text, the top bar, yeah this newsletter thing to upsell with these crappy (but effective) marketing techniques...
Somehow I feel old school websites (HN, Reddit, and so) are more sticky, more addictive, more unique. They focus on what we really want: contents and communication with others.
Another thing I realized it's nonsense lately: object oriented programming.
It's often an over-engineered bloat that only works for trivial Programming 101 courses (yeah the famous Employee or Bike class). But in 10+ years of programming, I found that OOP is just a complete mess (you end up with awful classes in your code like Service, Manager, AbstractFactory, and so).
I wish we could just use variables and functions, that's all we need really. :)
It depends on what kind of development you're doing.
For most web and business programming I've done, at the end of the day I'm mostly just taking data and transforming it into other data. Most of the time, looking at these programs as a series of functions through which data gets piped to obtain the result works well. As a result I think that functional programming is a good fit a ton of code that is written using OOP. For fun, I tried converting some old side projects to F#. Once I'd gotten used to the language, I ended up being able to express the same ideas more clearly, and with fewer lines of code. Functional programming isn't magic, but it can be very effective when used in the right places.
Lately, I've been getting into game development as a hobby. And when I'm simulating a miniature world with hundreds or thousands of stateful actors, I find that OOP works really well - in that the way to code models the game world aligns well with my mental model of the game world. You absolutely can program games using a functional style - I've just found OOP to be a better fit here for my uses. It's still useful to use a functional approach where you can, though, even inside an OOP game code base. John Carmack has written and spoken about this.
> I wish we could just use variables and functions, that's all we need really.
You still can. You need decent data structures too, but I never in over 20 years really "got" OOP. It seemed needlessly complicated. Functions and data always seemed to do the job for me.
OOP as most people get to know it seems to be a bleak application of the original concept.
And the original was not aimed at dealing with the internals of a single program sitting on a single CPU, but grand simulations running on massive clusters. There each "object" would could very well be a process of its own, running on its own dedicated hardware.
Effectively OOP became another one of those buzzwords on the bingo board...
Hit counters, guestbooks, web rings, autoplay midi files, under construction gif animations, cursor animations, HTML frames, etc. We've been adding unnecessary garbage to webpages since almost the very beginning of WWW.
I'll add another thing to your list - segment! It's so weird to me to see a homepage load, look into my dev tools and find that my browser is talking to Facebook.
Neither of those are an option on Chrome/Android, and I don't think they apply on Firefox/Android (not sure about disabling JS).
Firefox does offer uBlock, at least, which is a massive relief. I also run (on the router) a large, and after significant modularisation by me, flexible dnsmasq blocklist that addresses another large set of issues.
On desktop (Linux, MacOS), I have and use: NoScript, uBlock, uMatrix, and Stylish, as well as Reader Mode.
It's still often less aggrevating to grab source or rendered text and create a standalone Markdown text, for various reasons.
I'm looking into the notion of a browsing mode that presumes the website designer is an idiot and that the HTML markup is at best a hint at what the semantic structure ought to be -- see concepts such as POSH (Plain Old Structural HTML), and ... a few other things. Work in (very slow) progress.
I think what guy is actually experiencing strong feeling of nostalgia for older times. And I understand that. I see it on myself more and more with coming years too. We were simply born in some era, which holds strong memories in us. We hold sentiment to old things (programs), because somehow they're connected with best memories from time we were much younger. And the best memories are usually bounded to age around 20 - 30. Ask senior to tell you a story from his time and there is high probability that the story will be from their younger times, than from older ones.
My point is, that maybe todays software is not all that bad. We just don't feel the same needs as 20 year old guy somewhere at Google who programmed it. And it also works apposite way too. Show 20 year guy Visicalc, what he will think about it. Or check teens reactions to Windows 95.
But maybe it is. On nearly every metric that matters to power users software is worse.
Control? We have less.
Options? Less.
Ownership? Not that we ever had it, but now you don't even get a disc. Licenses are even more restrictive.
The pace of 'upgrades'? Way, unnecessarily faster
And when the business dies now? Now you're fucked.
There are stories of mechanics running their shops today with 40-year-old dinosaurs, where their biggest logistical issue is getting old parts to repair when it breaks. It was sad that the magazine article I read that story in laughed at the "backwards" proprietor, when in fact he is a hero for standing up to the current trend of users-as-serfs cloud everything.
> The pace of 'upgrades'? Way, unnecessarily faster
Not only that, but the availability of easy upgrades has incentivized companies to sell unfinished software and hope to patch fast enough in response to user complaints, instead of even bothering to actually finish the product as marketed.
You've answered your own question... more people are learning to program, from fewer and more professionally run sources, which preach a gospel that prizes engagement, conversions and ease-of-use, over empowerment, functionality, or choice. Plus, with this larger and more mainstream community, where 'coders' are pulled in off the street with little technical knowledge (let alone passion) who never grokked complex apps anyway, produce what they know. The end result is a sea of gimped, appliance-like 'apps' that do little more than funnel users towards business objectives.
And when the business died, their software still ran. Hard-won expertise kept it running. No stupid CEO or developer could stop you, and neither could they pull the rug out from under your feet with a sunset or some other shitty move. You bought your software and that, mercifully, could be the end of your relationship with that publisher.
You worded your initial response like you were referencing actual stats about software. I'm sure you think you and your colleagues are reliable sources, but to the rest of the world, they aren't.
Every single one of those statements was subjective. Don't be fooled by my use of the word 'metric'. It is, frankly, amazing that people here expect one to have facts and citations for every little nitty point.
It's not about having a "fact or citation for every nitty point"... It's about having even a tiny grain of self-awareness before making a statement about the global state of software in 2017, and perhaps having the self-awareness to know that, generally speaking, your anecdote ("citation") is meaningless.
I guess at some point I need to stop being surprised that HN comments are really no better than Reddit's.
Well the only way a 20 year old is getting weirded out by a Win 95 interface is (1) he has never seen a Windows machine because Win 10 basically reverted to the same Win 95 interface or (2) never worked on a desktop/laptop with KDE, Cinnamon or the other DEs inspired by Win 95. And Win 95's UI rocks IMHO (and I say that as a person closer in age to those annoying pipsqueaks in that video). You go to a button labeled "START". It has clearly labeled folders called "Accessories", "Programs", "Internet" etc and then you get to where you want to. For 90% of the UIs, a tree like that is a perfectly good data structure.
The more annoying thing is why is it that software like Office etc take two orders of nagnitude more RAM while being essentially 90% similar in functionality to Office '97
> You go to a button labeled "START". It has clearly labeled folders called "Accessories", "Programs", "Internet" etc and then you get to where you want to. For 90% of the UIs, a tree like that is a perfectly good data structure.
The strict hierarchy of the start menu was admittedly pretty nice, right up until (I think) Windows XP, where they started having the weird bifurcation at the parent level.
> My point is, that maybe todays software is not all that bad.
Well, as an interface designer who is supposedly in the age category where his best memories are still being created I feel a bit insulted, because from my point of view, a lot of things are pretty bad. Don't get me wrong, things are also a lot better, but there is more to life than HD video, better color fidelity, novelties made possible by virtual reality, and the interconnectedness of the web - even when these are all big improvements over the past! But it does feel like the computer is being domesticated into the new TV.
As far as interfaces themselves go, the main culprit (from a design POV) is almost always the priority of touch-first design, with mouse a distant second, and keyboard input only existing for things that could not removed through dumbing things down, like input forms.
Now touch interfaces are great in some areas, but any time I have to select/copy/paste text I am painfully reminded of their limits. In general it feels like 90% of the time I am struggling to do things that would be trivial with mouse and/or keyboard. And let's not even go into the lack of tactile feedback[0].
Even more insulting is that it is not that hard to make an interface that supports different modes of input, or where the potential keyboard input is easy to understand. There even exist modern quasi-innovations like react-select, which uses a select field for mouse and touch and lets you type to autocomplete among available options for keyboard power-users[1].
The opening line about perceptual slowness also rings true. In my childhood we had long loading times because of slow hard drives or CD-drives. Now we have them for the sake of saving development costs and adding ad revenue. The internet is a bloated mess, which from a content perspective it doesn't need to be at all; many websites work better if you turn off JavaScript[2].
Then there is web development itself, starting with a reliance on bloated overly generic modules, all the way down to the metal where there is an unawareness that there is even such a thing as an ever increasing memory/processor performance gap, or that this might also affects JavaScript code.
Well, it does, and not even browser vendors themselves seem to be fully aware of it. For example: on all platforms that I've tried, a simple radix sort is between two to eighty times faster the built-in sorting algorithms when sorting numbers, for all array types, regardless of whether it is in-place or a sorted copy[3]. (in the use-case for which I investigated it, the improvement is five to ten-fold, allowing me to do interactive animations where before I had to resort to slow renders). The difference makes sense for plain Arrays, which cannot assume integer values, but why the heck are the typed arrays so slow? They're plain contiguous memory array; compared to all the other browser complexities this is about as simple as it gets!
I could go on for a while but the point is: it's not like things were better in the past. It's just that a number of these things should have gotten better and instead seem to have regressed. And I know it's complex combination of many reasons, but it's still saddening to see.
What's really annoying and frustrating to me is that, even with a browser extension/plugin like Vimium, websites and webapps seem to almost go out of their way to break my ability to use my keyboard.
A lot of the changes that break usability for me are purely cosmetic changes that, e.g. replace a `button` with an `img` or `svg`.
The corporate culture to release a product in time rather than having it perform fast ruined the IT world and is infecting the FOSS ecosystem too. Just throw away all VM-constrained or interpreted languages (or use them only for prototyping) and the problem is almost solved.
Then make everything work offline unless it is absolutely necessary to do the opposite (backups, updates etc). Rediscovering the lost art of optimization would also help a lot.
This does not work. The economic incentives are biased towards fast releases of mediocre software. Whoever delivers faster and cheaper tends to win.
Quality is detrimental to the business. Good software does not require support. Paid support earns money.
An initial release that is stuffed with features takes longer to develop (the competition gets the customers) and has fewer incentives for later upgrades (less income after initial release).
Software cannot really improve unless quality standards become mandatory. The liability disclaimer should go. Engineers don't get a free pass if their products don't work. Why should software be treated differently?
Funny to have a rant on UX on medium not suitable to long form posts.
It is sadly very similar in desktop realm. You can’t copy text from the most part of the interface. There can be an error and you have to rewrite it to find what is this all about. The computer has this already written down, it’s just silly. That is the one thing that usually is better about webapps. Of course there are silly designers who want to expose their users to the same limitation, by blocking copy or context menu. But usually they don’t do this, because it’s more work.
That’s why CLI will likely never die. By default you can manipulate the data to your heart’s content. It may be slow and sometimes half-assed, but it still will be faster. You don’t have to rewrite anything. It’s a bit sadly the closest we have to a data-oriented system. Where one can manipulate all available information without massive hurdles. Only with some hurdles.
What else: Oberon, Plan9 interfaces (Acme!), Powershell, AppleScript (? - when I was using OSX at work few years ago I couldn’t find reference manual of the language), certainly more throughout the history.
We can’t do anything useful in 2d and yet we are working on VR/AR interfaces where undoubtedly we will make same mistakes (and more!).
Recently I discovered how well sapGUI works from the UX perspective. It is essentially an glorified graphical 3270 terminal emulator which runs applications that very often rely on user entering cryptic but human readable IDs (there is lookup functionality integrated in essentially all such fields, but frequent users typically do not use it that much).
Another interesting fact is that the 3270/sapGUI/dynpro model is almost perfect match to how HTML forms work (with the inline lookups and such stuff being the small part that would require some trivial JS/AJAX). I don't understand why today's web apps universaly try to reinvent the wheel by being "single page", emulating desktop WIMP interfaces and such things when simple HTML would work perfectly fine.
Edit to add another point:
For our anime conventions I wrote our own online ticketing system. It has web interface for customers and general administration, but the on-site box office uses ncurses interface which intentionally has very ISPF-ish feeling to it, genral consensus of the staff seems to be that it is significantly more efficient and intuitive than web based systems used by other local conventions.
3270 is really fascinating evolutionary dead end. I don't have first-hand knowledge (wish I had!), but as far as I can tell it is bit like high-level ncurses/dialog(1)/forms built in directly to the terminal layer. Of course being very proprietary very enterpricy tech, there isn't that much information about how it worked in practice, but it certainly feels like a very different path for UIs.
3270 allows user to edit screen contents without interaction with host computer and allows host computer to mark screen regions as user editable or not. Interaction with host mostly consists of sending (text) framebuffer contents back and forth.
SAP's dynpro is abstraction layer on top of that which presents somewhat higher level view of that (forms and fields, not framebuffers and characters) and also allows 3270's behavior to be emulated on normal character-oriented terminals (obviously by ncurses-like software running on host). This abstraction is sufficiently high-level that sapGUI can look like somewhat modern desktop application instead of obvious 3270 emulator. (Windows version of sapGUI allows you to render parts of UI as embedded HTML or ActiveX components, but that capability does not seem to be used that much outside of SAP's development tools)
From programmer's point view it is not that different from web 1.0 application built on semi-modern form handling library (eg. WTForms or whatever your all-in-one webapp framework provides). Probably only difference is that for web frameworks you will have if(form_submitted_and_valid()) somewhere, while in SAP body of that conditional and rest of the controller implementation are always two distinct procedures.
This lends itself to supporting functional physical design. I'm getting tired of the screenification of everything. I don't want a touchscreen in my car. I want a bunch of knobs that I can reach for, feel, and use without looking at them. I cannot do this with a touch screen.
i strongly agree. a physical thing is just more expressive, and when designed right, that can be leveraged. cars are the example ne plus ultra of how touchscreens arent always a great idea
> And it's worth noting that HYPERTEXT, specifically, is best with a mouse in a lot of cases. Wikipedia would suck on keyboard.
A decade ago I would navigate web pages quicker than now. I was using Opera, which had keys for navigating from hyperlink to hyperlink (spatially, using shift+arrow keys). It also keys for navigating to the logical previous and next page--that is, not navigating history, but following "link rel=prev" and "link rel=next" links. Unfortunately, the web evolved to make this harder. Everything is a hyperlink and no one uses link rel tags anymore.
The thing that horrifies me about all of this is that instead of criticizing or fixing issues most people adapt what they do and even how they think to match all the deficiencies in software. Often, users simply can't imagine systems that work fundamentally differently and better. Often, when deficiencies are pointed out people start defending the mess and pointing out all the clever (half-assed, really) workaround and hacks they came up with. They are proud of all the time they spent (wasted) learning about obscure and counter-intuitive software functionality. They are proud that barely-working plugin/extensions/add-on they found and set up. All of that to do thing that should be trivial to begin with.
One counter-point, though.
> I make no secret of hating the mouse.
If you look at the original uses of the mouse it was great. Especially in systems like Xerox Star. Star allowed people to perform complex tasks with almost no learning curve.
(Note how they weren't shy of using keyboard either. There are dedicated hardware buttons for standard commands like copy, find, repeat, "properties" and even for common text editing actions. Meanwhile, our keyboards don't have dedicated keys for undo, redo, cut, copy and paste - operations that are used in almost every application today.)
Trouble is, we lost most of the driving ideas behind Xerox-style interfaces. Using a predefined set generic, powerful commands. Object-oriented UI. Uniformity of representations. Modern system have those things only as vestigial traits and in very limited contexts.
I don't think there were any quantum leaps in conceptual UI design since Xerox Park times. There were some minor improvements in very specialized apps and significant regression in software that's used universally. For examples, phones and tables almost completely lost drag-and-drop functionality and generic file UI.
For example, drag-and-drop is a very powerful concept, because it allows you to perform actions by combining things you already know about - and those "things" figure out how to interact in the best way possible. So, for example, instead of having N "Print" buttons in N applications you can have a singe drag-file-onto-printer-icon action that does different things based on the type of the file. [BTW, this is also the key idea behind the original notion of OOP.] Unfortunately, that's not how it works in modern UIs. They don't use either the keyboard or the mouse to their full potential.
People get used to doing things a certain way. When they have to overcome a terrible interface, an attachment forms. It's no different than the pride of those that live in physically harsh environments.
I think a lot of the perceived slowness is now the fact that so much more is reliant on the network now - and more often than not requires several hops over the public internet to some data centre somewhere.
I'd not be surprised if the author's library search terminal from the 80s had a local copy of the index, or at least the index was stored on a server on the same lightly-loaded LAN as the terminal.
My home laptop is hugely, hugely faster than ones I've had a decade ago for local workloads, but my network connection's latency and bandwidth have not improved nearly as fast.
Network latency can be one reason but I found the lack of optimisation to be a bigger factor. As long as a programme somehow works many developers won't try to optimise it. That gives us Electron apps which are easily 10x slower than a comparable native app (pgAdmin is a prime example).
The day I sold my Atari ST, I pulled it out of the stack of old computers, connected it to a monitor, hooked up a disk drive and turned it on.
Poof: Desktop with a working mouse cursor in under one second.
I booted a nearby PC, and then hit reset until it booted. In the time that the "hot shit" 386 box took to get to a DOS prompt, the ST booted about fifty times. To something with graphics.
Modern system boot times depress me. We have database servers that take 15 minutes to POST. Doing updates or diagnosing hardware-level issues with these things is g l a c i a l l y slow. I work with message queueing systems that are not shy about several seconds of latency -- what are these stupid things doing? The datacenter they're running in is less than a hundred microseconds wide, and everything is high-end XEON CPUs with SSD and more cache than the first 30 computers I used, put together.
Everything is faster when you build it into ROM. The cost is flexibility. Should you wish to run another OS on that ST, ypu would have to bootstrap it through TOS.
I've since built systems based on flash that boot in tenths of a second, with over a thousand times the memory of that ST. I'll point out that the PC BIOS the ST was competing with was also in ROM, and only spent the last couple seconds of its execution loading stuff from disk -- I think the test was more than fair.
I'm still thankful for https://tinyapps.org even well after it has gone nearly read-only!
To qualify for TinyApps, a program must:
1. Not exceed 1.44mb
2. Not be adware
3. Not require the VB/MFC/.NET runtimes. Also, preference is given to apps which are 100% self-contained, requiring no installation, registry changes, etc.
4. Preferably be free, and ideally offer source code. Shareware will only be listed if there is no freeware alternative.
Fortunately we still have a choice. That's also one of the main reason I'm always using command line if it makes sense. In most cases you get instant or near-instant results. Our lives are too precious to waste them on sitting by the computer and waiting for the results - only because some people decided we should do it this way, and other people followed, and still other people had to implement it, dealing with mediocre infrastructure and additional complexity, usually with mixed results.
> i posit that nobody wants autocomplete-style live DB lookups. They don't fit the mold that autocomplete fits in.
1. I live-code an example in about:blank with devTools window open.
2. I roll my own little jQuery-like closure for the sake of convenience.
3. It works.
4. I close the browser and forget about the thing.
5. Later, I decide I wanna test out a feature of the Web Animation API, so I open my browser to about:blank again.
6. I remember that I used a little closure last time-- as I type the var name Chromium pops up an "autocomplete-style live DB lookup" menu. At the bottom is My Little Closure from last time!
7. I move the mouse down to the relevant line in the menu. Or, I use keyboard arrows to navigate to it. Or I keep typing and narrow down the menu options.
Useful? Check. Discoverable? Check? Obtrusive? Negative-- in the case that I don't every want previously typed expression, that menu option is put at the bottom out of the way of the more common JS internals and DOM methods.
Default settings in a terminal (or terminal-based GUI) generally require the user to either type something to get into a history mode, or type tab to do completion. But both of those options are less discoverable-- they require me to know ahead of time that I want to retrieve something. With devTools it shows me what can be retrieved so that I know what's available even if I'm a neophyte.
Its 2017 and I wait for my computer. I wait on Linux, I wait on Windows. This sucks hard. It is still complicated to search for stuff or to morph data from one representation into another. The web is even worse. And lets not talk about sharing data or other computer-resources with others.
When looking back at what people invented in the 80s till today, I hardly see much progress.
I don't care much about how much RAM an application takes, I care about speed. The next big OS should have a golden rule, never make the user wait. That's the ultimate goal which all OS's fail to address today.
What I want in the end is most times some text which is layout in a visually pleasant way, some images, some videos. I thought multiple times about writing a program which would fetch all data from all the websites I'm interested in, messengers, email-accounts and so on and store them somewhere – so that I could later view them (with whatever program) without any fucking delay.
My experience is that everything is slower than when I first started using computers as a child in the 90's, and it does it worse. You don't own anything anymore, upgrades routinely take away features, and nothing interfaces with anything else.
There are a lot of reasons why building an app on a web framework makes sense, but the fact that I routinely lose access to applications I've paid for because the company has gone out of business or stopped supporting them drives me insane. I can still install Excel 97 if I want to, but I have 0 confidence that anything I've bought from Google will work a year from now.
I mean, there is perceptible lag in character entry that never used to happen. Sure, my computer used to freeze inexplicably, but Atom crashes often enough that I don't consider that a win, and text has a noticeable delay before it appears on the screen when using Atom. Text entry is something I can implement flawlessly on a microcontroller and the majority of applications I use on a daily basis get it wrong.