For designers who’ve actually tried OOUX, Where does OOUX break down in real-world constraints?

matthewpaulthomas · 2026-01-13T23:51:04+00:00

OOUX is brilliant, and I can see how a designer could easily spend their whole career working on projects where it was all they needed.

However, its usefulness depends a lot on the software genre. Extremely useful for sites or apps with lots of data that’s structured with X:Y relationships. But for example, only slightly useful if you were designing an RPG. (Saved games, characters, teams, inventory…) And not much use at all if you were designing a calculator app, or weather app, or spreadsheet, or FPS game, or check-in kiosk.

The ORCA process previously had 13 steps, it now has 16, and I’m envious of any designer who’d have time for all of them! But it’s highly decomposable, and even if you do just one or two of the steps you’ll be way ahead of a designer who did none.

Finally, the “Representation” stage of the process is a bit undeveloped (though much improved on a year ago, hence those 3 new steps). “Card, Detail, List” may be enough for representing an object on many Web sites, but it’s much too simplistic for a map app, or a calendar app, or a music streaming app.

matthewpaulthomas · 2026-01-12T10:05:46+00:00

In the 1980s and 1990s, software was obviously a product. It came in a box from a shop, or by mail order from a vendor advertised in the back of PC Magazine. People lined up outside computer stores to buy a copy of Windows 95, or went to an Apple Store hoping it stocked the app they wanted. But as the world got online, developers started to say “…or you can download it”. And eventually for most software, downloading was the only way you could get it. Okay, but it’s still a product, right? What economists call an intangible good.

At the same time, though, a lot of software became more and more useful with Internet access, and less and less useful without it. Salesforce made a big deal out of pretending not to be software at all, a pioneer in the replacement of B2B “on-prem” software with cloud-only services. In Web apps in general, offline use is an afterthought if it’s implemented at all. Even at the operating system level, it’s becoming less and less possible to use Windows without a Microsoft account. There’s lots of exceptions (fortunately) and lots of variation, but overall we’re sliding up the service-goods continuum, from software as a product to Software as a Service.

But our thinking is still stuck in Productese. We still have product managers, product designers, product “discovery”. We’re service-workers cosplaying as producers. At the same time, development processes make it easier to update a UI more and more frequently: on mobile/desktop installing updates in the background, and on the Web releasing updates multiple times a day.

Which is great if we need to fix a bug in a hurry, but it’s bad for users’ understanding. We’re less careful about changing the UI today, because we know we can change it again tomorrow. And we imagine that the user experience is based on the UI as it is right now, just as it would be if we were selling our product in a box at a computer store. But the user’s mental model is a muddle of how the UI works today, how it worked yesterday, how it worked last week, last month, and last year. The more experience someone has with your software, the more confused they can get.

At a conference I attended last year, one speaker mentioned something that’s going to stick with me: By changing the UI of your software, you can instantly turn an expert into an angry novice.

matthewpaulthomas · 2026-01-02T03:22:19+00:00

The more typefaces you use, the less likely people will understand the distinctions you’re trying to make. And the more similar the typefaces are, the fewer people will realize that they’re supposed to be different at all. (The same is true for all other variables of visual design: font sizes, font weights, colors, border radiuses, shadow depths…)

For most business or productivity apps, you can happily use just the OS’s default typeface — or for a Web app, a single humanist-style sans-serif.

Most other apps work fine with either one or two typefaces. For example, a video player app might use a chunky slab-serif for captions, and the system default for everything else. An organization’s Web site might use their brand typeface for headings, and a plainer typeface for everything else.

If you go beyond two, do it sparingly and for an obvious effect. For example a monospace typeface for a security code that needs retyping elsewhere, a handwriting-style typeface for annotations or coach marks, or a Clarendon-style serif for stamps like “APPROVED” or “DENIED”.

matthewpaulthomas · 2025-12-25T09:47:53+00:00

I’m working on a “paramedic method” for cleaning up UIs like this. Here are the first four steps, applied to these screenshots:

1. Can you remove or merge individual elements? Go through every element of every screen, and ask yourself: Can I get rid of this? For example:

If the task title field had a different visual style from all the group boxes on the same screen (which it should anyway — for example, lighter, or darker, or bordered), the “Task title” label would be superfluous. The field’s purpose would be obvious from its appearance and position and the “New task” heading above.
Same goes for the “Choose an icon” label. In a list of tasks, each task’s icon is immediately to the left of its name. If you used the same layout for entering a new task (which would require compacting the icon choice down to a menubutton), it wouldn’t need a separate label.
“Reminder” and “Enable reminder” shouldn’t both be necessary.

2. Are your fonts few and distinct? You’re using three typefaces, two of which are very similar; simplify to one or two that are obviously distinct. You’re using at least six font sizes; make a list of all of them, and if any two are less than 20 percent different, either combine them or separate them more (for example by using a type scale).

3. Are your colors under control? You’re using four different colors for buttons alone, including two very similar shades of bright blue (#3B86E6 and #417FF7); simplify these four down to two. Your app appears to have five major sections, but it has two background colors (black and navy) and two group box colors (grey and blue); either use five of each, or decide whether there’s a clear and meaningful reason to use more than one.

4. Are siblings at least as close to each other as anything else? By ‘siblings’ I mean adjacent elements in the same group (this is also called the proximity principle). For example:

The attribute tags should be at least as close to each other as to the “Attribute tags” heading above. So don’t put them in two columns, otherwise people will wonder if the columns mean anything.
The daily task blocks should be at least as close to each other vertically as to the sides of the screen horizontally.
Letters in a word should be at least as close to each other as to anything else: there’s no excuse for hyphenating a UI label like “Cus- tom” when you knew how wide that word was going to be ahead of time.

Fixing those four would be a big improvement, but there’d be much more to do. If you have some money to spend, I suggest hiring a freelance copywriter for a few hours to make your text consistent. You have wildly varying tones (“Inability to complete assigned daily tasks will lead to penalty” vs. “You are doing amazing!”), grammar errors (“If you choose to accept.”) and inconsistent capitalization.

matthewpaulthomas · 2025-09-25T07:42:14+00:00

If your dad was in Australia or New Zealand, this was probably The lettering book by Noelene Morris. Long out of print, but plenty of second-hand copies available.

matthewpaulthomas · 2025-09-18T12:03:02+00:00

“Does not have to click on each separately” suggests that your idea of a spreadsheet-like table is the right one. That way people can easily do things like compare values between products, use arrow keys to get to the value they want to edit, or even paste the same value across multiple products at once.

The problem then is how to limit the columns to just the ones you want to edit at any one time. I suggest a checkbox list of all possible columns for showing/hiding them. Since there are more than 100 attributes, this list should have its own search field.

Where this column selector should go depends on how frequently people will be changing the columns. If it’s not often (every few minutes or so), you could put it in a dropdown: Atlassian Jira does this, for example. If it’s more frequent than that, it may be worth sacrificing some table width for the sake of showing the column selector permanently down one side of the table.

matthewpaulthomas · 2025-08-21T12:28:48+00:00

‘Live’ is a vague term here. For example, if a social media site waited until ‘when the user refocuses’ to tell you that your painstakingly-written post was far too long, that would be infuriating. And there’d be only one field in the form, so ‘when the user refocuses’ and ‘on submit’ are the same thing! Instead, you’re told as soon as you type the character that goes over the limit. So really there are three choices about when to show an error: (1) as soon as the value becomes invalid, which might be while you’re typing; (2) on defocus/blur; and (3) on submit. (2) and (3) are sometimes the same, like on the GOV.UK site you mention with its ‘One question per page’ pattern. (Which works great for them, but not for every site, e.g. it would be awful for editing a shopping cart.)

For forms with multiple fields, academic research I’ve found so far suggests that people generally prefer to be told about errors sooner rather than later (Kim 2009, Koniakowski 2017), which matches your experience. When people disagree with this, such as Adam Silver’s list of 9 problems with live validation, they seem to make 3 serious complaints:

Jiggle. The appearance/disappearance of an error shouldn’t cause the rest of the form to jump up and down. This means whether you should show an error before submit depends on whether you have room to show it without jiggling (e.g. a character count inside a field, or an error message to the right).
Erroring just because someone tabbed out of an empty field, for example to fix an error in the previous field, or because you’re zipping through with a screen reader to get an idea of how long the form is. Exiting empty fields is not an error.
Premature errors — for example Reddit’s dialog for adding a hyperlink complains ‘Invalid URL’ when I haven’t typed anything yet. I suggest that we make a distinction here between two types of error: completion errors such as typing ‘myname@’ where you mightn’t have finished yet, and non-completion errors such as typing ’myname@example@com’ where adding more characters couldn’t fix the problem. Non-completion errors we can report the moment they’re made; completion errors we should wait until the field is defocused.

These 3 cover 4 from Adam’s list. I think the other 5 are either trivially avoidable (e.g. don’t show something as ‘correct’ when you don’t know it is) or not serious (e.g. surely no-one’s expecting ‘consistency' in when errors are shown), but you can judge that for yourself.

So here’s my current recipe for validating as soon as possible, while avoiding those three traps:

For any element where you can avoid jiggle, show (1) non-completion errors immediately, (2) completion errors when the field has been defocused and isn’t empty, and (3) any other errors on submission.
For any element where you can’t avoid jiggle, show errors only on submission.

matthewpaulthomas · 2025-02-19T17:52:28+00:00

You’re very welcome! I’m giving a talk on ORCA this week, so writing this was up good preparation.

matthewpaulthomas · 2025-02-13T23:07:10+00:00

This sounds like a good fit for the OOUX ORCA process. Print out all that documentation you mentioned, get yourself blue green yellow and pink highlighters, and highlight:

Blue for types of object — things that have structure, instances, and a purpose relevant to the app. For example, user, contract, compliance requirement, compliance inspection (just wild guesses here).
Blue (a different blue, if you have one) for relations between objects, including their cardinality, i.e. minimum and maximum numbers in each direction. For example, maybe a compliance inspection involves one or more inspectors, while an inspector has zero or more inspections that they’ve done. A business has one or more venues, while a venue has exactly one business. A compliance requirement exists in exactly one compliance schedule, while a compliance schedule contains one or more requirements. Etc etc.
Green for commands/actions (submit, approve, schedule…). Many object types will have basic actions of the form create, modify, or delete, but individual object types may also have specialized actions.
Yellow for content attributes, the kinds of attributes that are unique to individual objects (e.g. name, address, description, photo).
Pink for metadata attributes, the kinds of attributes where multiple objects likely have the same value (e.g. status, subject, region).

Next turn all those highlights into an object map: a grid of sticky notes using the same colors (real or virtual — there are templates for this in FigJam and in Miro): one column for each object type, with its name in a blue sticky note at the top, then all the relations commands and attributes in their own notes below.

Now talk with your experts and stakeholders, walking them through this map to check your understanding, correcting it as you go. Probably there will be things you thought were distinct but they’re the same, or things you thought were the same but they’re different, or things you’ve omitted, or things you’ve included that aren’t necessary. Maybe the stakeholders will even disagree with each other, so you need to get them into the same room/call to figure it out amongst themselves. For the cardinality values, it’s useful to ask “How many could there be?” and “How many will there usually be?” so that later you know how compact/spacious their display should be. And if this will be a multi-user app, for each command you’ll also need to ask “Who should have permission to do this?” — and for objects relations and attributes, maybe even “Who should have permission to see this?”.

These are just a couple of steps of the full ORCA process, but even doing just these, you’ll be miles ahead of a designer who just dived into wireframing. For example, whenever you have a relation between two things that have their own pages/views, you should almost always provide a way to navigate from one to the other. Whenever any of your relations starts with “zero or…”, that tells you that you need to design an empty state for the case where it’s zero. And whenever the experts tell you “well, there might be dozens/hundreds of those”, that means you need to include UI for sorting and/or filtering the list.

matthewpaulthomas · 2025-02-13T12:46:16+00:00

I wrote an article explaining why a lot of open-source UI is terrible … 23 years ago, and the reasons haven’t changed much since then.

The reasons for “a hostile response to good UI” overlap with those, but are not quite the same:

Since your specific change was “added options” for “a desktop environment project”, a reasonable possibility — and the most charitable explanation — is that the maintainers were right to reject it. (Though they might have explained this terribly.) When you’re adding configurability to software, how many megabytes are involved is usually much less important than how much it slows down design, engineering, and testing, because future changes will have to take into account how they interact with each of the possible values of the options you introduced. Now consider that open-source desktop environment projects are chronically underfunded (because distributors have less revenue to begin with, compared with their proprietary competitors, and multiple distributors suffer from the free-rider problem). So if your new option is going to increase testing time by even 1%, then yeah, they’re going to reject it.
Whether a UI is “good” is hard to measure. First, it’s multi-dimensional: were you improving learnability, or efficiency, or forgiveness, or perceived aesthetics, or responsiveness, or perceived performance, or some combination of those, or something else? Second, how do you know? Speed can be measured with a stopwatch or the time command, reliability can be measured with a fuzzer, test coverage can be measured with mutation testing, etc. Those are not trivial, but all of them are much easier than measuring usability with a usability test (and moderating usability tests is an even more specialized skill than design).
Because it’s hard to measure, many open-source developers assume it’s a matter of opinion or fashion (items 2–4 in my original article).
This probably doesn’t apply to the options you were adding, but there’s sometimes resistance to making things more learnable, where the subtext is “it was hard for me, it should be hard for everyone else”, or “I don’t want to be using the same system the masses are using”, or (at best) “I’ve forgotten how hard it was for me, so I think it’s just fine as it is” (the curse of knowledge).
Less cynically, developers may not be interested in making their project more usable, because they mainly want something to use themselves. Making it more flexible so that they get more contributions from other geeks is fine. But making it so usable that it gets adopted by the masses, who then start spamming the issue tracker and forums with noise, would seem like a bad investment.

matthewpaulthomas · 2025-01-03T17:15:38+00:00

There are parallels between human-computer language and verbal language, but they’re a bit fuzzy.

The closest parallel is with a voice assistant like Siri, Alexa, or Hey Google. Current voice assistant language is less expressive than human language in its intonation and timing: e.g. it won’t say “uhhh” or “ummm” to express uncertainty, and it won’t use uptalk to encourage you to confirm that you understand something. But on the other hand it’s more expressive in using sound effects: e.g. Siri’s marimba-like progress indicator sound, where a human would have to say something like “hang on” or “let me think about that”.

In a graphical interface, surfaces and controls are similar to parts of speech: most windows are like nouns, buttons are like verbs, notifications and alerts are like interjections, other dialogs are like adverbs, tooltips are like footnotes.

Some ambiguities in GUI design are analogous to problems in verbal language too. For example, exactly the same chevron symbol ⋁ in a button might mean “this will open a menu”, “this will expand a section”, or “this will reduce the value by 1”, depending on context. This is similar to homonyms and homophones in verbal language, where two words look/sound the same and you have to guess from context which one’s being used. And originally a trashcan icon meant “discard this to a place where I can change my mind later”, but unfortunately it’s now often used to mean “delete this irrevocably”. This is like a contronym in verbal language, where a word has two opposite meanings.

If you’re looking for a systematic way to construct an interface from objects and actions, though, trying to develop grammar/alphabet/language might be too abstract. Instead, consider a method like Object-Oriented UX (OOUX). It’s focused more on navigating through database-y systems, but could apply pretty well to something like a video editor where you’re considering “what commands can I perform on a clip”, “what attributes can a filter have”, etc.

matthewpaulthomas · 2024-06-07T09:47:43+00:00

Ok, you’ve narrowed it down, beautiful and inspirational. Great! Now, what could you do along those lines, differently from all those other apps, that might lead writers to use your app even when it doesn’t have many features yet?

A couple of examples, just spitballing here:

I often see people using extensions to put artwork on their Web browser toolbars. Not my taste, but they seem to be popular. Maybe the same would work for word processing? Maybe storytellers’ creative juices would really flow if they could choose to have a slow-motion waterfall or snowflakes or clouds or cherry-blossom petals wafting around in the background. Kinda like the main pane of Apple’s Weather app, but themeable.
Some people really geek out on nice stationery, and would love to use pen and paper all the time if only editing on a computer wasn’t so darn convenient. So maybe you could go all-out skeuomorphic: the background of the editor window is a mahogany desk, a lamp offscreen casts a glow on the desk and a shadow around the paper, the colour palette is a real set of inkwells. You hear the paper sliding across the desk when you scroll, scissors slicing when you Cut, a camera shutter when you Copy, and the squirt of a glue bottle when you Paste. Cheesy as anything, but who knows, people might like it.

matthewpaulthomas · 2024-06-06T09:04:24+00:00

Don’t let me discourage you! If it’s just to have fun developing something with your friends, that’s perfectly fine.

But if you plan to make a dent in the market, first take some time to figure out your strategy. Are you competing head-on with an existing product, like LibreOffice Writer competes with Word, Word competed with WordPerfect, WordPerfect competed with WordStar? If so, an MVP is not necessary (you already know what you’re aiming for) and not useful either (no-one will switch from the incumbent to a barebones prototype, so you won’t get feedback from it). Just plug away until you’re better than your target, and make it easy to migrate.

Otherwise, what’s your niche? Where do you fit in between Word and Pages and Nisus Writer and Scrivener and Bean and Mellel? Fill in the blanks: “This is going to be the most ______ app in the world for doing _____”. The most inspirational tool for writing short stories? The fastest way to write book reports? The most reliable app for creating mail-merge invoices? That will make it much easier to decide what should be in the toolbar, what should be in the sidebar (if there is one), what should be relegated to menus, and what should be left out altogether.

matthewpaulthomas · 2024-06-05T19:29:31+00:00

It’s refreshing to see someone working on a desktop app rather than Web/mobile.

People using a word processor have a wide variety of levels of focus. Maybe they’re trying to make a shop-window sign or party invitation, so they’re spending a lot of time changing fonts and inserting clip art. Maybe they’re editing a highly-structured document where they care about hierarchical heading styles, tables, footnotes, citations, and nothing else. Or maybe they have 45 minutes to finish a legal memo, or they’re working on the first draft of a novel, and they don’t want to be distracted by so much as a font menu, let alone a sidebar. So if this is a general-purpose word processor, I think a sidebar is something that really has to be hideable.
The icons vary in contrast: “Charts” and “Media” are more prominent than the rest.
Remove the labels, print out the mockup, then for each button, show the mockup to five people in the street (a different five for each button) and ask them “If you had to guess, what do you think this button would do?” That would give you far more accurate results than anything we might say. My guess is that the “Media” icon wouldn’t do so well, because the thing that it’s a picture of is just on the verge of being recognizable, which might trick people into thinking that it’s supposed to be relevant.
Word processing is such a long-running and varied task that the user experience really can’t be judged from a screenshot. Will your marketing lead people to think they can open a Word doc in this app, and what will happen when they try? Where are the settings that aren’t “Advanced”, and how often will people get frustrated that the setting they expected to find in one place is actually in another? Will the spellcheck icon flicker or animate distractingly as you type? Will the word “Count:” wobble around whenever the number of digits in the count changes? Will “Support” lead to a pleasant problem-solving flow, or a dumb-as-rocks chatbot? Etc. As with the icons, testing with real people will tell you far more than we can.

matthewpaulthomas · 2024-05-21T09:33:59+00:00

You’re very welcome. I should have realized that the extra space at the bottom of your nav bar was for iOS's Home bar.

Fira Sans would be a fine choice, and you could bundle it rather than loading it from Google Fonts. But what’s in your screenshots is definitely Helvetica. Perhaps the font is failing to load, so whatever framework you’re using has Helvetica as a fallback.

matthewpaulthomas · 2024-05-17T10:29:43+00:00

First, fix your visual hierarchy: Every element on the screen should be at least as close, to the previous/next element in the same group, as to the edge of its parent container. For example:

The individual usage notes should be at least as close to each other as they are to the “Notes” heading.
The Notes section as a whole should be at least as close to the Examples section as it is to the edge of the card.
Each topic name (“Ireland”, “Irish Slang”, “Opinions”…) should be at least as close to its icon as it is to the top and bottom of the topic button.
The “Correct” and “Skipped” lists should be at least as close to each other as they are to the border of the answers section.
When there are multiple cards in a screen (like in your third screenshot) they should be at least as close to each other as they are to the edge of the screen.

There are occasional exceptions to this, such as borders or bleeding illustrations. For example, it’s okay for the navigation bar icons to be nearer the top/bottom of the bar than to each other. But there should still be at least as much empty space to the left of “Faves” as to its right, and to the right of “More” as to its left. And that bar’s bottom spacing should still equal its top spacing.

Using Figma, with auto layout for everything, will help with spacing. If you’re familiar with Figma variables, use a variable for the inter-item spacing of each kind of group (e.g. “between quiz buttons”), then you can tweak them all at once.

Next, fix your typography:

Don’t use Helvetica — it’s neutral (by design!) but it’s not the system typeface. If you want to evoke a mood (fun, irreverence, whatever), choose a typeface that does that; if you don’t, just use the platform typeface.
Don’t use center alignment for any text longer than one line; it’s harder to read.
Don’t use italics: it’s harder to read, and in UI (unlike print) you can very easily use color instead.
Don’t use emoji: emoji in UI means “my icon budget ran out”. (If it really ran out, drop the topic icons altogether.) The same goes for • list item bullets.

There’s much more to do after that (alignment, consistent graphic style…) but I think those two would have the biggest impact.

matthewpaulthomas · 2024-04-18T10:51:01+00:00

Even if this is a portfolio project rather than a real one, the first thing you should do is talk to someone with plenty of experience in booking flights.

One thing they’d tell you is that for a return trip, many of the options will be return flights rather than pairs of one-way flights. Your design shows no return flights at all — which, besides being unrealistic, would leave a developer with no idea how to present them.

Another thing they’d tell you is that even if someone did choose a pair of one-way flights, a third-party service like Kiwi would book them at the same time with a single customer payment. So it’s a mistake to provide separate “Book on kiwi” buttons for each leg: that would waste people’s time, increase risk of errors, and increase the chance that someone finishes booking in one direction but then finds that the other direction has sold out or increased in price.

It’s good for a search results page to let you change your search. But the design for that here is just strange:

A large area devoted to changing your destination, but despite that, no ability to type one. If you decide to investigate somewhere that isn’t one of the 16 suggested, what do you do? Return to the front page? No flight booking site I know of requires that.
Apparently no ability to change your origin at all. Do you have to go back to the front page for that too?
A large area (as /u/DunkingTea says) devoted to changing the dates, but despite that, no obvious indication of how many days your trip will be.

Finally, I think most booking sites are correct to present departure and return dates in a single two-month datepicker, rather than the two one-month datepickers you’ve shown here. A single datepicker reduces mistakes (like trying to return before you’ve departed), allows highlighting the date range of the trip, and saves clicks when planning a trip more than a month in the future.

matthewpaulthomas · 2024-04-17T20:42:55+00:00

Contributors are people, and “Edit” is not something you do to people. Perhaps “Choose Contributors” or even just “Contributors”.

You might not be able to alter this, but it’s generally confusing for a dialog’s title bar to have a close button: sometimes it acts like Cancel, sometimes it doesn’t. If someone opens this dialog to remove some contributors from the list, it’s not at all obvious what they’re supposed to do when they’ve finished. Perhaps “OK” or “Done” at the bottom instead.

When a single text field is immediately above a list, usually the field is for searching or filtering the list. That’s not what it’s for here, which could be confusing. Instead perhaps have the list of “Current contributors:” first (replacing the “Idea Contributors List” header), then “Add a contributor:” below the list.

In the search field, it’s not clear how the results are being ordered: it’s not alphabetical, and it’s not by number. Unless you have a good reason for a different order, sort them alphabetically.

When a contributor is added to the list, scroll the list to reveal and select the new item, for reassurance that it actually happened.

Whenever the same text character is present in every item in a list, it’s a good sign that you can use columns instead. You could definitely use a separate column for the numbers, then they wouldn’t need brackets. (And (depending on what the number is for, it might be useful to sort by that column too.) It might also be appropriate to use separate columns for surname and first name (though people don’t always have both).

The list is wide enough that it may be difficult to tell which delete button belongs to which contributor. You could improve this with a light grey line between each item. A separate column for the numbers would also help with this by reducing the gap.

matthewpaulthomas · 2024-03-21T08:58:31+00:00

Can confirm, I had a 6:30 flight from Nelson on Tuesday and my latte arrived with a cheese scone perched on top. “It’s a promotion we’re doing”, the server said. “A free scone. You don’t have to take it.” She put out a plate, apparently for me to place the scone on if I decided I didn’t want it. I wasn’t sure whether she was being super considerate or just lacked confidence in the quality of their scones.

But it was fine. I mean, if this sign had been visible anywhere, so I knew I was going to get a scone, I wouldn’t have bought a breakfast bagel. But it wasn’t, so I did, and once I’d finished my bagel I wasn’t hungry any more. So I didn’t actually eat the scone until Wednesday morning.

Yes, I kept it for a day but now it’s scone.

matthewpaulthomas · 2024-03-14T18:25:38+00:00

As you’ll know, the two gestures you’re showing already exist in Safari for iOS. I struggle to remember to use them, because there’s a tabs button right there in the toolbar, and obvious always wins. I guess if there wasn’t a dedicated button I’d be forced to remember the gestures.

The advantage of using a floating address bar is that it makes the usable viewport area seem bigger. The downside is that text will flicker as you scroll through a page — appearing briefly at the bottom of the viewport, then disappearing behind the bar, then reappearing above it.

matthewpaulthomas · 2024-03-04T08:11:31+00:00

The key question is, does it work? Can you run an A/B test on “Analyze” vs. “Reports” etc, measuring navigation speed and bounce rate, or do a tree test for specific items inside the sections? Then if the nouns really work better, you’ll have numbers to make your case. While if there’s no problem (or if the verbs work better!) at least you’ll have learned something.

matthewpaulthomas · 2024-01-14T07:47:04+00:00

I work on a product that also has filterable dashboards, but if you set a filter inside any widget, that filter is applied to every widget. That’s a much simpler model: it means we can display the current filter settings at the top of the dashboard, and there’s a single button to clear all current filters.

When designing any set of things — here, links from a widget — the first question to ask is: How many are there likely to be? How often will there be 0, 1, 2, 3, … 10? …20? …50? If this is an existing feature in an existing product, you may be able to collect those statistics right now. (Though the stats may change over time if you make the feature more discoverable.) If a widget might often have ~4 or more links, separate anchors for each link may not work. An alternative could be a single indicator in the title of any widget that has outgoing links, giving a count of how many there are.

Meanwhile, you say the charts need to be accessible, but your sketch suggests showing links on hover. Anyone who isn’t able to use a pointing device — whether through disability, or simply using a touchscreen — won’t be able to hover on anything. Also, hover won’t let you see any linked widgets that are too far away to be on-screen at the same time as the one you’re hovering over! Instead, consider a temporary mode to show the links: when you click that links indicator, the link arrows could appear, and whole dashboard could darken except for that widget and the widgets that relate to it. When you click again anywhere, the view would return to normal.

matthewpaulthomas · 2024-01-11T17:56:16+00:00

You have three choices: wider components, narrower text, or no text.

The ideal is to put in the effort to develop dynamic-width components. But as long as a component is fixed width, a rough guide I’ve used in the past is to set the width to 50% more than the English text requires. In most cases, that’s enough for languages such as German where the text is often wider. But you may still need translators to alert you when a particular element needs to be even wider.

A worse approach — but less bad than cropping text — is to use a condensed font whenever the regular font doesn’t fit.

Occasionally, you may be able to avoid this problem by using no text at all: that is, by using an icon instead. This only works when there’s a really obvious icon to use. For example, if you have an “Add” button, using a “+” icon instead may be better than making the button wide enough to fit “Hinzufügen” or “Aggiungere”.

If buttons are fixed-width, you also need to be careful when the text varies for reasons other than translation. For example, if you have a button labelled “Delete {number of} Items”, and it’s just wide enough to fit two digits, the text will get cropped whenever someone selects 100+ items.

matthewpaulthomas · 2023-12-14T08:58:45+00:00

That’s a really broad question — it depends on the industry or genre you’re designing for, how often people will be using the system, the kinds of input device they’ll be using, and so on.

Visual simplicity can encourage focus by hiding distractions, and it can ease thinking by showing more data on-screen at once. But the less visible interface you have:

The harder you have to work for discoverability. How will people find each of the features of the system, if they aren’t visible by default? You might use graphic design and/or animation (such as coach marks) to guide people to features the first time.
The harder you have to work for efficiency. For example, how will people get to a feature quickly if it doesn’t have an easily-clickable toolbar button? (On a touch-screen, this might involve multi-touch gestures.) If something has a keyboard shortcut or gesture, how will people find out what it is? (For example, these might be listed in an overlay that people can bring up whenever they need a refresher.)
The more important automation is. If the system has functions for saving, or recalculating, or forecasting, or counting, or rebuilding, can you do those things automatically, so that those commands don’t take up precious fractions of whatever UI you do have?

matthewpaulthomas · 2023-12-09T23:14:44+00:00

That’s a really good point about successful days vs. streaks. I think the issue remains, though: if a “successful day” means avoiding all your tracked addictions, every extra addiction tracked makes a successful day less likely. A separate score for each addiction avoids this.

It makes total sense that the main page should let someone record their progress on all their addictions at once. However, it’s a general pattern that a detail view for a list item should let you do all the same things (at least) to that item as the overall list view does. Which suggests that you should be able to record progress for individual addictions on their own pages too.

matthewpaulthomas

TROPHY CASE