Jan DInternal consistency of interfaces is curious: It makes software easier to use but it can not be easily tested for, since it is in no testable feature in particular. If you test with people who know your software, it has an effect, but it rarely can be isolated. Here, it makes a lot of sense to use expert reviews.
see also: "User interface evaluation in the real world: a comparison of four techniques" https://dl.acm.org/doi/10.1145/108844.108862
Jeff Miller (orange hatband)@simulo I complimented the consistent design of LaunchDarkly's production property flag management UI and their designer reached out to discuss it with me.
It might even have been on Twitter or Mastodon rather than via an embedded survey in the product, I can't remember.
Having opportunities for engaging with users is one way to open a source of UI fitness to purpose.
@simulo The Silicon Valley Patterns Group discussed Jenifer Tidwell's UI pattern language and that's still my reference point for different ways to orient UI/UX around the role of the software for the user.
When I looked up Ms. Tidwell, it appears that she has moved out of infotech and into a hands-on career in her own business doing design and decoration with plants. I confess a bit of envy.
@jmeowmeow I have not read this! I'll have a look.
@simulo I recall particularly the distinctions in Tidwell's UI pattern language around transient posture UI (a helper for tasks, like an arithmetic calculator or glyph lookup) versus sovereign posture UI (dense and designed to be worked with, using most of the user's attention; spreadsheets, perhaps, or computer aided mechanical design). Different contexts of interaction drove different solution patterns
There seems to be productive overlap between Tidwell's application postures and Cooper personas for who needs what from UI, for what purpose in what context. The famous example demonstrating Cooper personas was the design of an airline in-flight entertainment system before everyone started bringing their own devices.
@jmeowmeow I had a look at the book, I like it a lot!
Was it common for the patterns group to invite people who worked with patterns outside of code?
Was it common for the patterns group to invite people who worked with patterns outside of code?
@simulo UI design patterns counted as code as far as the Silicon Valley Patterns Group was concerned. I arrived late enough that the group had gone from "read the GoF Design Patterns book together" to a more general informal seminar in interesting topics relevant to practicing programmers, which included design and show and tell on technologies and (as one example) interoperability testing for the Jini protocol.
@simulo The O'Reilly book on UI design patterns came after the pattern language paper we had discussed, but I suspect that the book content is an extension of the paper.
@simulo We never had Jenifer Tidwell participate directly in the discussion of her UI pattern language paper. I had looked her up (to find her landscaping business) because the UI pattern language seemed like foundational work, and wondered if she had developed more in that area.
@jmeowmeow If I understand her 1997-99 work correctly, she was active at hillside and other parts of the pattern community.
I still wonder why there were so many similarities of interface guidelines and pattern collections, yet both rarely seemed to have touched.
I still wonder why there were so many similarities of interface guidelines and pattern collections, yet both rarely seemed to have touched.
@simulo I wonder if there were different traditions feeding into software architecture and microarchitecture (Design Patterns; very directly taken from evolved wisdom in building and city patterns; anthropology) versus traditions feeding HCI from industrial and military applications of perceptual psychology and safety-critical systems
@simulo I have a Internet Friend acquainted with the Alan Cooper design studio and its methods, and that procedure is a different discipline from HCI as taught.
I wonder if Cooper's books ("The Inmates Are Running the Asylum", criticism of naïve HCI lacking insightful design) may have emphasized the separation of agile methods (favored by some but not all Design Patterns folks) as producing unreflective design, from engaged and reflective user-oriented design.
I don't see these points of view as being fundamentally at odds. but rather as useful perspectives for dialogue and choices.
@jmeowmeow
> emphasized the separation of agile methods
Possibly – agile is very developer oriented, "The inmates..." can be very hostile towards developers setting up a division to argue why it needs design. An interesting contrast with the Apple Interface Guidelines that seem to try to reform them.
@simulo Yes, and I'm glad that I got to listen in on the discussions and get some context for where the ire comes from.
One of the occupational hazards in infocomtech design is that one can envision a perfect scenario, for a delightful or liberating tool, but feel disappointed that it wasn't quite realized.
And it can feel natural to point out and blame those who stood in the way of perfection.
XKCD Tasks comes to mind, indirectly, where "identify a bird" might be "figure out what the user intends". Sometimes there is irreducible complexity or ambiguity which hopefully is clarified in design or prototyping.
@jmeowmeow Yes, that makes sense. I wonder if in practice, it might be something like "developers relating their work to Alexander's patterns" and "guidelines for (macintosh productivity app) developers on how to not mess up their interfaces"
@simulo The Mac was serious about UI designs, sometimes to a fault, AND that tradition was important as a reference point which had broader influence.
But that's me talking through my hat; I have only been a student of UI design and a victim of it, not a designer.
Spoofer3@simulo A couple of things that I've found related to better, more consistent UIs...if the underlying business logic was built from Command pattern first, possibly in cli/repl and then later have a gui put on it, and 2, that the GUI is written for a specific user or role. That is, it's not just an aggregation of widgets. And then within the context of serving that user/role, that menus, actions, gestures, etc do similar things in similar contexts makes the learning transferrable across contexts.
Maybe another way of stating the above is to have a quality UI, it's much easier if it starts from quality foundation of understanding the problem domain and understanding the solution for that domain. It seems many UIs are the evolution of the developer learning about the domain.
@Spoofer3 yes, command pattern is very useful for building UIs upon!
Some thoughts:
- When it is missing, I have trouble finding out how I could improve the UI via code
- It works well with different programming styles (there are functional equivalents like action/reducer in redux. mathy.)
- maps directly to menus and toolbars. Drag-and-drop is harder, but doable (needs a preview layer!)
- With some additional work, it gives undo/redo (This is harder for live collaboration obviously)
Some thoughts:
- When it is missing, I have trouble finding out how I could improve the UI via code
- It works well with different programming styles (there are functional equivalents like action/reducer in redux. mathy.)
- maps directly to menus and toolbars. Drag-and-drop is harder, but doable (needs a preview layer!)
- With some additional work, it gives undo/redo (This is harder for live collaboration obviously)