Semantic Zoom
alexanderobenauer.com
alexanderobenauer.com
Edit: more specifically, Archy: https://en.wikipedia.org/wiki/Archy_(software) which has its roots in the “Zoomable user interfaces in scaleable vector graphics” paper (which I can’t find a working link for right now)
For those who don't know, Raskin proposes an alternative the reigning windows and folders paradigm, in which your entire OS is a single sheet, a kind of landscape in which you can zoom out to a map view or zoom down into specific words and images, a kind of google maps for your digital space.
It's always stuck with me and I would love to try it. Figma comes to mind as a popular product that's put the idea into practice, but that's a specific use case rather than "your whole digital world".
Not having used a Canon Cat, I can’t speak to the reality of how well that works. But ^S/^R are pretty close.
Of course emacs has all sorts of navigation commands, the Cat had LEAP and PAGE, and part of THI was “one way to do things”. I doubt many rely on incremental search for all navigation in eMacs.
The other concept was the modeless operations on selected text. In the Cat the idea was you could type in some simple math, select it, evaluate it, and replace it with the results. Out of the box I’m pretty sure you can select a Lisp expression and replace it with it evaluated result. Either way, you can see how straightforward it is to do whatever you can imagine to a region in eMacs.
Pretty sure there’s a way you can adapt eMacs to automatically save and reopen all buffers when you exit and re-enter eMacs. What you lose is the undo history.
Anyway, I think that eMacs captures a lot of what THI was trying to do.
> Universal use of text – Raskin argues that graphic icons in software without any accompanying text are often cryptic to users.[11]
It's frustrating helping my mother, or anyone else who doesn't innately understand current design trends, and having to explain what a "hamburger" menu is, or that they need to click the magic three dots and then another vague icon with no accompanying text.
This seems like such a sensible idea to me, it makes me wonder why it isn’t commonplace yet. I hope it will be!
Why isn't it commonplace? I think that touchscreen laptops are still too much a minority, and keyboard + mouse + monitor are too entrenched, for anyone to seriously attempt it again for a while. (A shame -- I'm one of the few who really liked the Windows 8 Metro interface.) I think that phones are too small for it to really work well. I don't know why it's not more popular on tablets.
The semantics of regular zoom are clear: scale+translate the viewport.
The semantics of "semantic" "zoom" are undefined. It's really just a smooth UI transition between different views. Those views could be anything, and the transition could be anything. So it's not really clear where "zoom" comes into this, aren't we just talking broadly about nice interactive UI transitions?
Sure, perhaps there is latent design space in using the mouse wheel / zoom gesture to navigate flat GUIs, but what is the accessibility story there?
Currently, there's still a good amount of rough edging from the mzscheme -> Racket rewriting, and support is primarily for MacOS and Linux.
Going forward, there's a lot of modernization to be done. In particular, Racket-on-Chez no longer affords escheme.h, so there's a lot of inversion of control to be done. I'm also working on and off on an updated multi-platform rendering layer to largely replace Pad++'a X Windows drawing, with the goal being to move more of Pad++'a logic up into the Dynapad layer in Racket.
When you're ready for some publicity be sure to put some description and images on the GitHub project. Right now it doesn't really say anything about what Dynapad is.
For the time being the REAMDE.macOS is likely to be the shortest path to getting things running. That said, it's mostly Intel specific. Running on M1 Macs presents its own set of tooling issues (to do with Racket no longer using GNU Lightning).
I still need to fully document that (unstable) process.
Sadly the version of scheme used is very long defunct. But the goal is to get everything modernized to the point this can be something you can work with (with minimal setup and work) using the whole modern Racket ecosystem!
Long time since New Mexico! We are also putting together some documentation.
Best, Jim
[0] https://twitter.com/ilographs/status/1651011570330206209?t=a...
Really excited about the work you're doing
The linked page[1] is an excellent example why potentially ingenious products can fail.
The writing on that page is as bad as it could possibly be.
There is an opening paragraph:
“Lively is a new approach to Web programming..”
which is nice. But next there are just three isolated links with absolutely no annotation.
What the heck is the reader supposed to do? I bet the ultimate majority will stop right there, close the page and think what kind of a mutherfucker could write such an idiotic page:-|
And I'd love help with a search query. Can't figure out the right words to avoid links about restoring old photos, or details of various MS Photos applications over the years.
Here is the research paper on PhotoMesa: http://www.cs.umd.edu/~bederson/images/pubs_pdfs/p19-khella....
And here's a YouTube video of PhotoMesa: https://youtu.be/CQYDhnBMoF0?si=SOWUcjSFyv47nfrt&t=59
Also, as a researcher who has studied and implemented Semantic Zooming, the original post (probably inadvertently) makes it sound like Underkoffler invented the idea. I'd have to double check things, but I believe it was Ben Bederson (also the creator of PhotoMesa above) and Jim Hollan that invented the concept of semantic zooming in their seminal work Pad++, which aimed to explore alternatives to basic GUI interfaces. Ben has a lot of papers looking at zooming interfaces for photos, presentations, calendars, and other visualizations.
Here's the paper on Pad++ https://dl.acm.org/doi/pdf/10.1145/192426.192435
No good UX should mess with literal zooming of web elements. I'm looking at responsive design and zoom-disabling apps in particular.
But when an app presents me with an interface to a ton of data, like Spotify giving me access to practically all the music I could ever care about, I would like to customize that interface as much as possible. Let's say, sometimes I might want to find the most popular music in a region, another time I might want to find sort regions by how much a particular song is popular. Maybe I might want to figure out the average length of all Jazz pieces, or the average volume.
The author talks about being able to achieve that through UX instead of SQL queries in general, and in this post -- about the specific idea of asking the UX to give more context about an element.
Spotify is actually a pretty good example of this, they've been steadily removing context for a while. It's gotten to where it's impossible to see more than 5 items at a time in a lot of their views.
Spotify is a weird one: I'd gladly pay 2x (maybe 5x?) Spotify's price simply as a database of music files licensed for my own personal consumption, provided I get to use my own Spotify client software because I don't want their Chromium-based UI[1] (for context, I'm still using Winamp). But Spotify aren't listening: they donn't want my money unless they get to control the UX, but I want to control my own UX, and even though I'm prepared to pay a premium to compensate them for their loss of access to my desktop they aren't interested.
Kinda reminds me of when Twitter Blue first launched: it still contained ads, and didn't come with any kind of Twitter API access to allow third-party clients. It's the worst of both worlds. It's definitely a part of platform-enshittification, but the frustrating part is that it's just unnecessarily harming the business via reputational-harm and poor power-user UX, and worst of all: leaving money on the table.
Sign language is a language.
> The heresy implicit within is the premise that the user, not the system, gets to define what is most important at any given moment
Calling that a heresy is about the most arrogantly flawed statement you can make in the field of user experience design, which is saying a lot.
In that sense, it is "heresy" -- not the current norm -- to put the user in charge of constructing the view of information in a system. It might be true.
Anyways, it took me a bit to understand what the author was saying, and the articles would be a lot easier to read if they used plain English. The articles are quite contextual and people with a different frame of view might interpret them differently, which is not good communication.
But it's still stupid. The system is still deciding.
I agree with the overall idea that users should have a lot of control over what they see and how, but just presenting this idea as the only good one (as implied by contrarian or heresy or whatever) is not the way to go. This could work for specialized creative workflows, and there may be a version of this that you could use for a window system, but I think as shown it would need to be targeted at very engaged and specialized users who can put in the work.
Is there a version of this idea that could work for general computing for a typical user? Maybe! But it would make a lot of decisions for the user at the end of the day; it would just need to feel like it didn’t.
1. This requires so much thought to implement and I don't think the average UX team can implement it. A half ass implementation of this will probably be worse than a simple page with hyperlinks.
2. This requires so much thought that each implementation will naturally diverge and so the user have to deal with hundreds of different unique and horrible UX.
From the example, when the app zooms into the "pace" page, how do I go back to the summary?