There's a footnote, attached in the wrong place, that explains the use of word "Heresy". It's used in a similar sense as "revolt", in the context of contrarianism.
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.
It’s worse than that. It forces the user to decide what’s most important from an interface design perspective at each moment while also doing the task. The fluidity is cool, and it helps maintain an understanding of hierarchy and context, but at some point the “system” needs to decide what’s important, or you’re just outsourcing design to your user.
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.
I've been using beautiful.ai to make slides. I like it, but it takes control over font size, and does so poorly - it frequently chooses a font size that is just too big for the space, in which case it blots out the text with an error message telling me I have too much text. If I ADD another character or word, it pushes the font size selector to the next smaller font size and now my longer text is ok where my shorter text was previously too long. There is no direct control over the font size, just this badly implemented system-controlled size picker.
I'm trying to do something very similar (if not exactly the same) to semantic zoom with architecture diagrams [0]. It's of course much simpler when the components are view-only and have a fixed UI. An entire design system for any kind of desktop/tablet app would be amazing.
Thanks! Yeah, you can certainly use Ilograph for C4. To see one layer at a time (the common way C4 is shown), set the detail slider, in top-right of the app [0], all the way to the left (low detail).
I get lost in these diagrams quickly, because they change constantly. I'd prefer architecture diagrams that solve multi scale display like maps do. Then, directions stay valid when zooming. I like to dive into different details coming from a common overview and getting back to that overview is much easier on maps than in such a view that constantly changes relative sizes and directions.
That was my first take as well, but after reading some of the previous articles by the author, it's not really about the size of elements on the screen. It's more about being able to "zoom" into information in a system, which is a part of the user selecting their own view of data in complex systems.
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.
It's no better. I want to compare a thing in item A to a thing in item B so I zoom in on item B and the thing I wanted to compare in item A disappears.
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 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.
Anyone remember the photo viewer from 10+ years ago that started with a tiled view of every photo and you zoomed in kind of organically to what you wanted? At the time it was revolutionary to me. Kind of in the Picasa era or earlier. I believe it was shareware or freeware and might have been Java-based.
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.
Those are very cool, but I'm talking about years pre-dating smartphones. I guess Picasa wasn't a good time marker in my question since it really wasn't retired that long ago.
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.
Anyone remember eagle mode: https://sourceforge.net/projects/eaglemode/ I remember playing with this in Windows XP days (perhaps even earlier). I think a lot of people assumed the window paradigm would eventually evolve, but it hasn't really.
I have a touchscreen laptop. I love it, but UIs like these would make me love it even more. Having information detail literally at your fingertips sounds amazing.
This seems like such a sensible idea to me, it makes me wonder why it isn’t commonplace yet. I hope it will be!
Something that would help speed up development of new interfaces would be applications having more extensibility in general. It happens so often that I come across a piece of software where I want to change just one thing, but there's no easy way to do it with plugins or extensions. The alternative is to create the software mostly from scratch myself, which is way too much effort that's just not worth it. Imagine what would happen if you could see all those small changes stack up, we could have so much more interesting functionality.
Windows 8 (Metro) used semantic zoom. It's been a while, but I do remember that one of the apps that used it very nicely was Photos. A search for "windows metro semantic zoom" comes up with lots of articles about semantic-zoom-aware GridView controls etc.
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.
I've often thought it was time to pick up Ben Bederson's work on Pad++ again, now that we have such great UI and hardware for zooming in interfaces. Here's a late-90s video of it in action: https://www.youtube.com/watch?v=BlIRYTuSv0Q
Some good news for you... Pad++ and Dynapad are in a decently runnable state again! Myself, Jim Hollan, and Tom Gillespie have been on and off working on refurbishing it.
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.
Oh that's exciting! And an interesting group of collaborators.
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 sure. The repo was actually just private until a moment before I commented above. The long term goal is to refactor to a point where installation can proceed with a minimal/straightforward CMake/Racket build, without any archaic dependency versions of weird hoops.
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.
Also to give a brief overview: Dynapad was/is a scheme based wrapper/GUI layer/scripting interface for building applications on top of the Pad++ primitives.
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!
This is hard to get right, but awesomely powerful when it works. The only collaborative whiteboard I've seen do this well is Plectica[0]. It has its other quirks but nails this part nicely.
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".
Mechanically, eMacs is quite close to THI. On THI the LEAP key was the fundamental navigation mechanic. It worked like a SHIFT or CTRL key, but it performed as an incremental search forward or backwards depending on which LEAP key you pressed. If you pressed (essentially) a META and tapped LEAP, it would search again.
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 looks good but will come out horrible in practice:
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?
"Semantic zoom" is a strange phrase because neither of those words describe what is happening (in this article). Note that the demos mostly involve clicking rather than wheel/zoom gestures.
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?
I agree. Its all custom, the developer is going to have to make decisions at every scale about what should be displaying. Its not a skin you can easily apply to all types of data.
This always looks amazing in the showcase video where the user does the expected gestures. But when you use it in real life, you want to kill yourself.
The examples on this blog are really quite neat. Can I download the software being shown, or are these just recordings of the author's private experiments?
Smalltalk solved this problem and many others a very long time ago but we are stuck with Unix and its variations. A live computational environment that can be molded by the individual for their own use cases was not commercially successful and so Smalltalk is now relegated to the dustbin of computing history instead of being the main paradigm for computer interaction[1].
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:-|
I really just want a 200ish dpi monitor that’s the size of a full wall whiteboard. Say something like 10 feet tall and 20 feet long. Touchscreen of course, but with alternate inputs too.
68 comments
[ 2.4 ms ] story [ 136 ms ] thread> 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.
[0] https://twitter.com/ilographs/status/1651011570330206209?t=a...
Really excited about the work you're doing
[0] https://app.ilograph.com/demo.ilograph.Ilograph/Request
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.
[1]: https://news.ycombinator.com/item?id=14088483
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.
https://eaglemode.sourceforge.net/
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
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.
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.
https://github.com/Dynapad/Dynapad/
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://beta.plectica.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.
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?
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?
https://uxdesign.cc/introducing-mercury-os-f4de45a04289
Sign language is a language.
1: https://lively-kernel.org/
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:-|