31–40 of 205 posts
That UI looks like something out of the late 80s / early 90s. I can smell the VCR head cleaner and scratch-n-sniff stickers and hear the dial-up internet bee-bee-bee-bee-gurglegugrle-dong-ding-dong-ding-whooooooooosh-wheeeeeeeesh-bling! bling whooooo. Can we at least upgrade the fonts, colors, and negative space to make it look more 2020s?
Earlier quoted context omitted.
From personal experience it's amazing how much more productive I am on solo projects vs working with other people. When you're solo you can just go, but in a team everything needs to be discussed or at least communicated.
Scaling software development has been THE vexing problem since day one. There's no doubt that the most efficient system fits in the head of a single person; the challenge is then what?
Earlier quoted context omitted.
Related to this subject is Casey Muratori's video about Conway's law and a possible extension to it. The communication overhead of working in teams, and the fact it's harder to address cross-cutting concerns in them, is a key theme in it. https://www.youtube.com/watch?v=5IUj1EZwpJY There is also Descartes' quote about how a work produced by one master is often better than one in which many are involved, because of th…
But one master cannot go to the Moon. It takes coordinated effort of many, many people. The same with making a-bomb, the same with making anything bigger in software. It’s nice that Linus started kernel and GIT but nowadays he’s not writing much code and most likely he would is not able to review personally each and every PR.
Right now, I'm working on my own on a personal project attempting to do something a little novel and I appreciate being able to go back and refine my ideas/previous code based on things I learn and additional thinking (even rewriting from scratch), when I'm more likely to face friction (like "stick to the suboptimal approach; it's not that bad") and cause trouble for teammates if I was working with someone else. So the value of working alone speaks more to me currently than the value of working in teams, but they both have their place.
It was ahead of its time in UX, but rather behind in the foundations. It's a single user system with no real security, and there was no system of shared libraries - to share code between applications, it was usual to put the shared code in a kernel module and call the kernel. Even the standard C library worked this way. Amusingly, when you invoked the system console -which was at a lower level than the gui system, ef…
I'm not even sure it was ahead in its UX; it had a three button mouse, and daily operations needed all three mouse buttons. I had to use them for years at school and I feel you could never quite be sure what the third button would do. In some cases, it was like what shift-click does today, in other cases it selected menu items without closing the menu, in other cases it moved windows without bringing them to front an…
Are you sure you're talking about RISC OS? Because you're got the overview right but your details are weird. Right-clicking never pops a menu in RISC OS. Only the middle button does that. That's why the buttons in RISC OS have names. They're not "left, middle, and right" they are "select, menu, and adjust".
The "everything is an object" drag-and-drop was absurdly powerful. You're not limited to dragging into a directory, you can equally well "save" a file directly into another application, avoiding the middle step of dumping it onto the disk first.
Personally, I find that the trend in making all UIs as easy as possible for the beginner to be a step backwards. Yes indeed, beginners can get going quicker, but then you've very quickly learned everything and there's no where to go. The pro user cannot work faster. The pro user cannot do more. We're all stuck behind fisher price interfaces.
If you treat users as if they are children, they will always use your software like a child.
Earlier quoted context omitted.
I'm not even sure it was ahead in its UX; it had a three button mouse, and daily operations needed all three mouse buttons. I had to use them for years at school and I feel you could never quite be sure what the third button would do. In some cases, it was like what shift-click does today, in other cases it selected menu items without closing the menu, in other cases it moved windows without bringing them to front an…
> you got different menus depending on whether you middle-clicked on the icon bar icon, or you right-clicked on the icon bar icon Are you sure you're talking about RISC OS? Because you're got the overview right but your details are weird. Right-clicking never pops a menu in RISC OS. Only the middle button does that. That's why the buttons in RISC OS have names. They're not "left, middle, and right" they are "select,…
Having just booted up RedSquirrel, yes, I accept I'm slightly misremembering. Right-clicking doesn't open a menu, it is consistently middle-click.
However, it is still somewhat inconsistent. In several applications (for example, !Maestro or a filer icon), left and right click on the icon bar do the same thing, while in others (for example !Edit), only left click opens a new window and right click does nothing.
Playing around with RISC OS 3.10 again, I'm also reminded of the nonsense that is menu items with arrows on them (indicating sub-menus, or sub-windows like save boxes) require you to successfully slide the mouse through the arrow to open them. Almost all other menus I've seen will open sub-menus as soon as you land _anywhere_ on the menu item.
While drag-and-drop may be powerful, the ergonomics of the UI were atrocious. I don't think anyone at Acorn had heard of Fitts' Law. The tiny save box also required you had exactly the right filer window open, ready and waiting. You couldn't easily change your mind like you can with a file requester (and also with modern MacOS's spring-loaded folders).
I also think the OS was designed with the expectation that overlapping windows would be _normal_, and I don't think that's ever been the case, certainly not how I use computers. Most windows I have open are fullscreen, and I switch between them (most commonly with the alt-tab concept that Windows brought). I might have _internal_ windows inside one app's window (for example, multiple code editing windows and terminals in an IDE, or tools, palettes and layers in graphics editing), but only on special occasions do I have two separate _application_ windows visibly open on the same screen, and when I do, they're usually side by side, not overlapping.
Earlier quoted context omitted.
Scaling software development has been THE vexing problem since day one. There's no doubt that the most efficient system fits in the head of a single person; the challenge is then what?
I read The Mythical Man Month recently (first published in 1975), and while some of it is charmingly dated (have a secretary take your code and run it down for you!), it's astonishing how much of its discussion and advice for structuring a team of programmers remains relevant even today.
Acorn was a curious company. It managed to get incredible amounts of work done, by assigning big projects to individuals instead of teams. My memory is not to be relied on at this lapse of time, but I seem to recall that in the final years there was a browser maintained by one guy, a port of Java by two, and an implementation of directX by another. Obviously all those projects were much smaller back then (around 98)…
I disagree that it always means slower time to market - if the individual is empowered and minimum process (no PMs, "grooming", estimates, etc) a sharp individual can run circles around a full team.
Earlier quoted context omitted.
From personal experience it's amazing how much more productive I am on solo projects vs working with other people. When you're solo you can just go, but in a team everything needs to be discussed or at least communicated.
Scaling software development has been THE vexing problem since day one. There's no doubt that the most efficient system fits in the head of a single person; the challenge is then what?
Acorn was a curious company. It managed to get incredible amounts of work done, by assigning big projects to individuals instead of teams. My memory is not to be relied on at this lapse of time, but I seem to recall that in the final years there was a browser maintained by one guy, a port of Java by two, and an implementation of directX by another. Obviously all those projects were much smaller back then (around 98)…
I recall seeing a Macromedia Director player but never heard of a DirectX port. In any case the lack of hardware floating point in most of their machines was looking like a big mistake by the mid 90s. Their compilers were also way off the pace and that was getting to be a problem. Tbh I think I am slightly bitter about having stuck with Acorn a bit too much, and should have jumped away sooner. It is clear Acorn knew…
[1]https://en.wikipedia.org/wiki/Network_Computer_Reference_Pro...
Earlier quoted context omitted.
Scaling software development has been THE vexing problem since day one. There's no doubt that the most efficient system fits in the head of a single person; the challenge is then what?
Either software development teams are a wonderful metaphor for multithreaded code, or multithreaded code is a wonderful metaphor for software development teams. I'm not sure which.