7 ms·
I spent almost 10 years doing IT for a company whose backend was based entirely on as/400. If you've ever used a system like that, I'm sure you know where this
by blhack 9y ago
I spent almost 10 years doing IT for a company whose backend was based entirely on as/400. If you've ever used a system like that, I'm sure you know where this is going...
The console's that the front-desk or clerical users used every day had a steep learning curve. It was something that you would definitely not be able to walk up to and just intuit.
However, once you figured it out, there is never going to be a faster UI that you are ever going to experience in your life until we figure out direct BCI stuff.
It was funny watching the new people come on board and insist that we should change the UI to something with a mouse (probably web based). They had no idea that more immediately intuitive was actually a step backwards.
My point is that just because something has a steep learning curve, that doesn't necessarily mean that it's a bad design.
- jakub_g 9y agoI work for a reservation systems company (a GDS) that is used by thousands of travel agencies. Of course, since the system was created 30 years ago, you were only able to create reservation with a text-based interface at the time, with short commands, inconsistent and complex flows to do some non-trivial things etc. So it's despised by newcomers because learning curve is steep. However, the company has been building new web-based solutions for a while, but all of them have so called "cryptic mode" where you can still directly input the commands, as it is order of magnitude faster, mandatory feature for experienced old-timer travel agents.
- Brotkrumen 9y agoAltea Amadeus. And all the three big GDS need to be thrown into a fire. "Oh you want to add a person to the PNR? Well tough luck! Not a use case we handle!"
- Brockenstein 9y agoYou should see how Sabre handles email address with it's bizarre, limited, possibly 7bit character set from 1959. In Sabre emails can be like 70 characters long. But periods count as two characters, as do underscores, and @ counts as four. I mean given the choice between period and cross of lorraine I know which I am choosing to include.
- hackuser 9y agoWhat character encoding do they use? ASCII is 7-bit, all those characters use 1 byte in ASCII, and of course email addresses were originally (and until recently?) restricted to ASCII.
- Brotkrumen 9y agoSomething weird: https://sds.sabre.com/XTRANET_Access/sabre.htm https://sds.sabre.com/XTRANET_Access/sabre.htm The @ is 0x2E20 in sabre hex
- VLM 9y ago"inconsistent and complex flows to do some non-trivial things" Note that's a characteristic of bad design, not a characteristic of CLIs, where constraining the UI to GUI, will merely result in a hard to use GUI, instead of a hard to use CLI. Note that in an email or printed page I can provide any CLI walkthru and anyone can follow with minimal training ("Which key is the any key?"), but some purely graphical GUIs are impossible to discuss verbally, especially if badly designed (see above, and realize the badly designed ones are going to need the most help). First, click on the icon that looks like a Rhinotia hemistictus nose, except its green. No, not that, thats more of a myrtle color, you want the really bright green one. OK, now if you see a screen that looks like a Type II Seyfert galaxy then you've clicked thru too far and need to click back. Oh no, there's no left arrow icon to go back, we outsourced development to save money and in the programmer's culture a left arrow is an obscene gesture indicating you mate with your sibling, so our discount software uses a thoracic vertebrae, superior side up, for its back icon, isn't that hilarious a "back bone" to go back oh those UX guys crack me up every time. Something thats one line at a shell interface that could have been cut and pasted in, can involve an hour of talking back and forth about a bad GUI.
- flukus 9y agoThere's a reason most desktop support still rely on the command line in the windows start menu.
- jakub_g 9y ago> "inconsistent and complex flows to do some non-trivial things" > Note that's a characteristic of bad design, not a characteristic of CLIs That's a characteristic of hundreds of developers creating features over dozens of years, and those features interacting with each other in subtle ways. In my experience, even in small projects and codebases things get notoriously inconsistent very fast. It's a hard thing to keep, as it requires conscious effort and most developers don't care that much. And once something goes to production (or far enough in non-regression phase), it's a game over. On top of that, AFAIU, in legacy systems, storage space was severely limited. Hence PNRs had a rigid structure that was not very extensible. That's another fact due to which implementing new features in a backward-compatible way might have been cumbersome.
- gadders 9y agoLotus 1-2-3 (the spreadsheet before Excel) used to have a text-based interface that people could rattle through. It was so popular, you can still bring up 1-2-3 text menu equivalents in Excel by typing "/".
- bauerd 9y agoThere's certainly a trade-off between learning curve and long-term productivity. But the problem here is that vi/m gives shitty feedback, that's all. It should say "Press <ESC> and type :quit<Enter> to quit VIM" but it doesn't. Most first-time users lack a mental model of input modes, so they get stuck.
- Ded7xSEoPKYNsDd 9y agoAfter pressing Ctrl-C a few times, the status bar says 'Type :quit<Enter> to exit Vim' for me. Not sure what else people try to exit vim.
- yjftsjthsd-h 9y agoThere's always C-z, but that actually works.
- gnaritas 9y ago> My point is that just because something has a steep learning curve, that doesn't necessarily mean that it's a bad design. It does if the app is aimed at companies with high turnover where said learning curve poses a continual problem for users.
- flukus 9y agoIf there is high turn over then the length of the learning curve is more important than the shape of it. Let's say there are two apps each with an employee starting, one requires two full days of training to be 90% proficient, the other allows for an instant start with a more gradual learning curve. After 30 days of employment the first has spent 28 days at 90% efficiency, the other has had 7 days at 60% efficiency, 7, days at 80% efficiency etc. A gradual learning curve could be much worse for companies with a high turn over.
- gnaritas 9y agoAbsolutely true.
- YeGoblynQueenne 9y agoI worked on Z/OS mainframes for a couple of years and the point-and-shoot interface is indeed very efficient, once you've learned to use it. The only thing I remember being really annoyed with was that there was no way (or no way I managed to find) to select all the text in a line in one go. The same was true for the editor (EZY). I kept pressing Ctrl + V to do a block-select and pasted all sorts of gibberish all over the place. Apparently, there are no line endings in text fields so it's not possible to get something like block-selection working. But that was about the only thing that sucked from my point of view and I grew up with GUIs and touch-interfaces, like everyone else in my generation.
- deleted 9y ago[deleted]
- Houshalter 9y agoI just hate programs that change patterns that are standard everywhere else. E.g. 99% of software uses control+c and control+v to do copy and pasting, so of course software that maps it to something totally different is going to be very frustrating. The same thing with vim using nonstandard way of quitting. Discoverability is another problem. You can have weird keyboard commands, but make it possible to find them without searching stack overflow. I miss when applications had a big bar at the top of all the commands you could do and their keyboard shortcuts. I'm on chrome right now, and copy and paste is hidden away in a menu. And the keyboard shortcut for it isn't mentioned. How do you think people learned the keyboard shortcut in the first place? Or apple phones have a bunch of gestures that are useful, but no one knows about because you can't discover them.
- dllthomas 9y agoApproximately 0% of terminal programs use control-c as copy. Conventions depend on context. "Control-C sends SIGINT" has been a standard for longer than "Control-C means copy".
- Houshalter 9y agoI'm well aware of that and the historical reasons that it's the case. I'm just using it as an example of breaking well established patterns that screw new users.
- boxfire 9y ago^C as copy is an example of breaking well established patterns that screw new users. Its THE canonical example in fact.
- Houshalter 9y agoI really don't care who is responsible or which came first. I'm only pointing out the inconsistency and the problems it causes.
- cm2187 9y agoI think your are mixing steep learning curve with having keyboard shortcuts (whether they are commands or combinations of keys). You can have keyboard based shortcuts with any UI. Actually a UI with no shortcut is probably a bad design in the first place. A steep learning curve just means it is hard to learn, i.e. non intuitive, non discoverable. These are not qualities.
- michaelwsherman 9y agoA bit late to the convo here, but one of the things that really impressed me about the Bloomberg (my employer) Terminal is how they manage this old user vs. new user problem well. The terminal looks like this now: https://www2.le.ac.uk/departments/economics/images/bloomberg/CGB0347a_edited-1.jpg https://www2.le.ac.uk/departments/economics/images/bloomberg... You can still do everything with the same keyboard shortcuts that have worked for 30+ years (pretty much everything with a number in front of it), and the layout of the screens generally don't change. But now everything on the mostly text-based view is clickable as well--everywhere you see a number you can click with a mouse. Additional shortcuts are hidden behind menus, like "Settings" in the photo. But if you know the shortcut, no need to look at "Settings" first (which itself can be opened by typing 97 or clicking it).