Hacker News Reader

Comment by rjmunro | Hacker News Reader

I always thought the beauty of RISC OS was in the UX not the underlying OS. The three most important things were:

1. Task bar / dock thing. This was well before Windows 95 and Mac OS X both adopted the feature.

2. There was a dedicated menu button on the mouse. This was the only way to get a menu, there no menu bars anywhere, freeing screen real estate. The other two mouse buttons were select, which behaved like a normal mouse button, and adjust, which did the sort of things you need to resort to shift-click on other platforms.

3. There was no file open dialog. You just double clicked a file to open it, or dragged it to the app that you wanted to open it with if you wanted to open in not the default. To save you would be presented with an icon which you could change the name of, and then drag to a finder window. No duplication of the folder system structure in a finder and in every app that handles files.

View on HN

The drag-to-save feature is incredibly under appreciated today. You could even drag the "file" from a save dialog into another app, rather than into a directory, resulting in a graphical way to do pipes.

Because TrackPad is getting popular. Dragging is comfortable for mouse but not good for trackpads to draggin long distance.

How is that better? You have to have already opened the directory where you want to save the file, or do it manually when you want to save instead of the application doing it automatically for you.

Absolutely. The UX was wonderful - pervasive scalable elements, lovely font hinting, and everything just felt "right"; the problem was that, like Windows 3.x and System 7, it was a co-operative façade laid over a single-tasking kernel.

If AmigaOS had the UX of RiscOS, or RiscOS had the multitasking of AmigaOS, it would have been a beautiful thing.

[on edit] Other people have mentioned the Basic implementation, and it was very impressive - far and beyond most versions, and very much a useful programming language with an accessible syntax.

I was going to say that they probably borrowed the dock from NeXTstep but now I see initial release of NeXTstep was 1989 while initial release of RISC OS was in 1987 ("Arthur") and already had a form of the dock, or at least a dock-like launcher.

Windows 1.0 had an icon bar at the bottom:

https://docs.microsoft.com/pt-br/archive/msdn-magazine/2009/...

That looks more like a task bar to me, and in the open Write document on the right it mentions "Rudamentary[sic] taskbar" which is what it's likely referring to.

The bar at the bottom in Windows is called the taskbar even today.

The chief difference between the Windows task bar and a MacOS dock is that some subset of icons on the dock are present even if the application hasn't been started.

Windows task bar can pin things to always be on it, even if it's not running, as well

That's the case on Windows as well, since Windows 98 I think.

[OP/article author here]

You could not pin icons to the taskbar in Windows 98, no.

Windows 98 integrated IE4, which contained a feature called "Active Desktop".

This was not a Win98 innovation -- if you installed IE4 onto Windows 95 or NT 4, you got the same features.

Active Desktop included dockable "toolbars" that could be pinned to the desktop or to any edge of the screen. One of these became part of the taskbar, and was called the "quick launch" bar.

It's a separate area for program icons. If you launch an app, you end up with _two_ icons: one in the quick launch bar, _plus_ an icon in the taskbar as well.

The Quick Launch toolbar is still present in Windows 10 today, in 2020, and can be turned back on very easily: https://mywindowshub.com/add-quick-launch-toolbar-windows-10...

Pinning launcher icons directly to the taskbar was a new feature in Windows 7 and was not possible before that: https://social.technet.microsoft.com/Forums/SharePoint/en-US...

Yeah, the key thing with the icon bar in RISC OS was that it showed running apps on the right, devices on the left. There wasn't really a 'launcher' component to it, and the blurred distinction launcher and running-app-selector bothered me a bit on Mac OS X (until I got used to it, I suppose).

How did you typically launch apps? Through the file manager kind of like classic Mac OS?

Yes. Most apps were 'installed' as a self-contained directory beginning with a '!', wherever you wanted. Double-clicking on such a directory ran the '!Run' script within it, which started the app. You could open up the app to see its component files by holding shift while double-clicking.

It was really quite a lovely system (very few installer programs, install/uninstall very clean with minimal dependencies), but it managed as well as it did mainly because nearly everything was statically linked and did its own thing for config. So centralised management of preferences was difficult, and what shared code there was (like the C library) broke the model a bit by needing to be kept in a separate '!System' directory.

As systems got more complex and ended up on the Internet, there was a greater concern for shared state between applications and security. Consequently the amount of stuff that started from disc on startup, the number of shared libraries and config files etc. went up, and some of the advantages of booting from ROM and the minimal 'copy to install' model went away a bit.

Yes it was called the Filer. Pretty much like the Finder on the Mac.

Isn't that just the minimized windows, like in Windows 3.1? Otherwise they must have removed the taskbar between version 1 and 3 but added it back in version 4 (i.e. Windows 95).

[OP/article author here]

No, not really.

Remember that Windows 1.0 was a primitive sort of tiling window system, because Microsoft was afraid of being sued by Apple and did not dare implement overlapping windows.

What you are seeing is a strip of the desktop background, which contains icons representing running programs. The tiling algorithm leaves a strip of "desktop" visible so that you can get to the program icons. This is how you switched between programs.

Windows 2 reintroduced tiling windows, but had no desktop icons as such -- again, it was afraid of being too like classic MacOS. This meant that you could rearrange windows, and so see the desktop. That in turn made it clearer that programs minimized to the desktop, as nothing else could be on the desktop.

This can be seen clearly if you look at screenshots of the work-in-progress test versions of "Windows Chicago", e.g. https://sites.google.com/site/chicagowin95/index -- this is what was to be Windows 4.0 but was renamed Windows 95.

For instance, in this one: https://sites.google.com/site/chicagowin95/index/chicago40

... you can see some running program's icons sitting _on top of_ the prototype taskbar.

There was no separate container for program icons. The taskbar was invented _de novo_ in Windows 95, and subsequent to the invention of the taskbar, icons representing running programs were moved into it.

I agree with you in terms of implementation. But having used Windows 1 for a while and reading about Arthur/RISCOS at the time my impression was that the user experience was similar. If I had been able to actually try RISCOS I might have had a different opinion.

While Windows 1 tiles might have been due to wanting to avoid upsetting Apple (though in terms of APIs and resource management it was mostly a copy) there were those who preferred tiles like With's Oberon (which I also used at the time, along with GEM and Geos).

Yes. Also extremely good native support for outline fonts and vector graphics.

The built-in !DRAW app was surprisingly powerful. It was clunky, but with practice it was possible to do some sophisticated stuff with it.

Yes, and it was implemented in terms of an underlying vector drawing module which could be used by 3rd party apps and even from BBC BASIC fairly easily.

Real-time spellcheck years before Office had it always impressed me.

Plus I have a soft spot for co-operative multitasking.

> There was no file open dialog. You just double clicked a file to open it, or dragged it to the app that you wanted to open it with if you wanted to open in not the default. To save you would be presented with an icon which you could change the name of, and then drag to a finder window. No duplication of the folder system structure in a finder and in every app that handles files.

Seems like a pain when working in a program and want to open a file

not really, you just find the file (using the full features of your finder) and open it the same way you always would. constrast that with windows, when you just choose “open”, then find the file and open it.

Another thing I just remembered was that if you dragged the bottom corner handle off the side or bottom of the screen, the other side of the window would grow. You could only grab the bottom right corner to change size, but this didn't matter because of the expanding feature.

Not sure how useful that save thing is in practice. Great for dragging into other apps, but to save to disk you still had to navigate through the filesystem anyway, just outside of the application.

Which sounds terrible, but only because we've been conditioned by apps that don't work well together. On Mac and Windows, workflows where you have multiple apps active at the same time are rare, and elements of the UI (e.g. sticking the menu for a single active application at the top of the screen) actively discourage you from using multiple apps together. In RISCOS the filer was pleasant to use, and the UI pushed you towards workflows that had different apps including the filer working together. It wasn't perfect, but it also wasn't as bad as you might think if you're used to the mainstream operating systems around today.

I was surprised when I switched from RISCOS to Windows just how much windows wants you to work in a 'single task' mode.

This is possibly the single biggest failure in all the modern OSs. Even though they multitask internally, single-task mode is baked into the UI.

Not only is there no easy way to compose application chains, the UX discourages you from thinking that applications chains might be possible.

Automation incredibly difficult - it's impossible for most people, and not easy even if you have developer-level skills. But worse, your data is locked into these monolithic applications. Project interchange isn't usually a thing at all, and data interchange formats tend to be lossy and/or unreliably implemented.

Pipes in a command line shell are a poor substitute for the wonders that would be possible with a common and easy to use composable and automatable UI/API framework and data interchange system.

Data formats may be the biggest blocker here. Think of all the ways copy paste goes sideways today. I've grown accustomed to always using the paste-plain-text way.

Data formats was one of the interesting benefits of RISCOS. Since there was a bitmap editor and a vector editor built into the ROM, any program where it made any kind of sense to could work with the vector format supported by the vector editor and the bitmap format supported by the system bitmap editor. As you point out, those standard interchange formats were definitely part of what and enabled and encouraged cross application workflows.

In addition, Mac and Windows always lift the most recently clicked window to the top, whereas RISC OS would not, making it much easier to set up a screen layout in which several apps cooperate as equals. I still find this to be a pain on my Mac today.

> Which sounds terrible, but only because we've been conditioned by apps that don't work well together.

Nothing to do with "conditioning". I had no experience of any other desktop environment at the time.

Aside from the task bar which I don't know its specifics, those examples aren't that great:

- A dedicated menu button on mouse is hard to discover. Mac's brilliance is that you can start exploring the UX right away without any prior knowledge of which button does what. It also prevents you from examining your options without needing to click anything. I don't think saved screen real estate is worth it. Mac & Windows did away with always-visible menu bars just fine. Remember how Windows 8 tried to hide the start menu and how it had turned into the worst UX experience in the last decade ever. Visibility is important for discoverability.

- "Drag & drop" has too much user friction. It's hard to discover, it's hard to apply properly (many beginner users think that leaving button mid-drag is okay for a short little while). It's impractical because you usually use your apps maximized (for the maximum real estate, remember?). It requires you to have the file visible and easily accessible (consider cluttered desktop icons). I stopped using drag&drop a long time ago, and resort to Copy/Paste function of Windows Explorer for copying files, which works brilliant.

"Drag & drop to open" has other issues too. For one, there is no orthogonality between open & close. Do I drag away the icon to close the file or is there a standalone "close" option without an open?

They might be novel ideas for their time, but I don't think they provide good UX.

> [Mac] also prevents you from examining your options without needing to click anything.

But it bundles selection-specific and system-general commands up in a remote menu bar that requires a lot of to and fro to operate. The beauty of right-click is that it gives a contextual menu specific to the object right there. I'd argue that it's fantastic UX.

> "Drag & drop" has too much user friction

Yet it's universally used for moving windows around the UI; click-drag on the title bar.

> Mac & Windows did away with always-visible menu bars just fine.

is this sarcasm? it appears disjointed from your comment and disagrees with your thesis.

> Remember how Windows 8 tried to hide the start menu and how it had turned into the worst UX experience in the last decade ever.

part of that is surely that trigger start in windows 8/8.1 closed (hid/whatever) you were working on before, forcing an unnecessary context switch. i can't print or save documents in office anymore for the same reason - if you choose “File”, it closes your current file.

note that mac os, windows, and to a much greater extent iOS and Android have abandoned the visibility principle. having a dedicated button vs a “force click” feature? i'd prefer the button.

your objections to dnd depend on it not being well implemented. but when it's core, it is well implemented. i use dnd, even sometimes to copy/paste on windows.

° "Drag & drop to open" has other issues too. For one, there is no orthogonality between open & close. Do I drag away the icon to close the file or is there a standalone "close" option without an open?

i don't understand your objection here. is there orthoganality between open/close on other systems? i have never thought so. i close by clicking x (windows, gnome) or just going back home (android). but i open by doubling click the file (linux) or doing something ad hoc (windows, android)

> is this sarcasm? it appears disjointed from your comment and disagrees with your thesis.

Not sure how it contradicts with my points. Can you clarify?

> is there orthoganality between open/close on other systems? i have never thought so.

Yes, there is always a "Close" menu option right in the same menu with the "Open". The close "X" is for closing windows, not opening them, and it also has orthogonality. You open the window by clicking on an icon, and you close it by clicking on another icon.

Going back isn't "closing" on Android. It's just the opposite of navigating forward which also makes sense in a navigational context.

> A dedicated menu button on mouse is hard to discover.

For what it's worth, it really wasn't. The meaning of at least the left and menu buttons was literally the first thing you would find out when being shown how to use the machine, and was on the intro sheet in the (extensive and excellent) printed guides.

The difficult-to-discover part was the right button ('adjust'), defined as doing whatever the left button did but a bit differently. So the left button might select a file, while the right button might add a file to the existing selection. Or a left click on the scroll bar 'down' arrow scrolls down, while a right click scrolls up (which was actually quite useful in pre-scroll wheel days as it saved a lot of precision mouse movements when searching documents etc.)

This is really analogous to the discoverability problems that guis have with modifier keys - the right button is basically a sort of ctrl-click without needing to put your hands on the keyboard.

But the menu button was just how you used menus. It was available and worked the same in essentially all applications and was really pleasant to use.

Ctrl-click is equally hard to explore. A beginner user's experience is entirely different.

Reply on news.ycombinator.com