Developer Tim Bray, of XML fame, has written an ode to The Sacred "Back" Button.
Younger readers will find it hard to conceive of a time in which every application screen didn't have a way to "Go Back". This universal affordance was there, a new thing, in the first Web browser that anyone saw, and pretty soon after that, more or less everything had it. It's a crucial part of the user experience and, unfortunately, a lot of popular software is doing it imperfectly. Let's demand perfection.
Why it matters · Nobody anywhere is smart enough to build an application that won't, in some situations, confuse its users. The Back option removes fear and makes people more willing to explore features, because they know they can always back out. It was one of the reasons why the nascent browsers were so much better than the Visual Basic, X11, and character-based interface dinosaurs that then stomped the earth.
Thus I was delighted, at the advent of Android, that the early phones had physical "back" buttons.
[...] Nowadays Android phones don't have the button, but do offer a universal "Back" gesture and, as an Android developer, you don't have to do anything special to get sane, user-friendly behavior. I notice that when I use iOS apps, they always provide a back arrow somewhere up in the top left corner; don't know if that costs developers extra work.
[...] People using your software generally have a well-developed expectation of what Back should do at any point in time, and any time you don't meet that expectation you've committed a grievous sin, one should remedy right now.
The undo function has been around since the beginning, though invented and reinvented several times. Some systems got it much later than others, but now its presence is universally expected.
(Score: 1, Insightful) by Anonymous Coward on Tuesday April 13 2021, @09:41AM
object-oriented data structures != object-oriented programming paradigm
Just because your data structure is object-oriented does not mean you have to use an OOP language and just because you are using an OOP language does not mean you have to use an object-oriented data structure. Some things are easier to think about as objects with attributes or are objects with attributes, so it is just easier to keep the data structured that way. Other things are not objects with attributes or are difficult to think of that way, so it is just easier to structure data in a different way. That's all that means. You are free to program around them however you please. For example, you can do object-oriented data structures in Haskell just fine, but they aren't objects in the OOP sense; and you can do non-object-oriented data structures in Smalltalk, but they are still objects in the OOP sense.