Some thoughts on design.
What's the minimum viable (for any particular feature) UI (MVUI) you could implement and start using via your website? - Tantek 11:25, 15 May 2013 (PDT)
Related article: https://petermolnar.eu/minimalism-is-not-asceticism/
Prioritize Through Use
Once you design/implement that MVUI and use it, by actual use in the wild you'll come up with a much more informed set of next-most-important-to-you features to implement. - Tantek 11:25, 15 May 2013 (PDT)
It's OK (and even often good!) to make incremental improvements to the design, however small or conditional.
For example, every time you reduce the number of situations where the user sees an error and/or has to file a support ticket, the likelihood of an overall better user experience is increased.
And on the contrary, avoid making such incremental improvements depend on other incremental improvements that can be done independently or later. Such dependencies are a milder form of the completeness trap.
UX Before Infrastructure
There is a misdirected priority/desire (often among developers/engineers) for things like:
- "a general message producer/consumer so I can implement it once" or similarly
- a general parser so I can implement it once
"...and then spend the rest of my time focusing on the UX" (ibid)
This is the kind of reasoning that led people to push for XML over everything else.
It was a misplaced focus on solving infrastructure *before* UX.
It turns out that doesn't actually help you solve the UX, which is the real challenge.
On the contrary, if you have good UX, then the infrastructure/plumbing can be almost anything, and swapped out later too.
This is perhaps a key distinguishing feature/aspect of the indieweb and IndieWeb efforts.
UX Before Protocols
Start with the MVUI/UX that you want on your website and implement accordingly.
When you reach a site-to-site boundary, i.e. an IndieWeb-to-IndieWeb boundary, in whatever feature you're designing, creating, iterating, use the desired UX to drive the design of a minimal protocol.
Never shoehorn upwards, that is from protocol up to UX - as that is the tail wagging the dog.
At the end of the day, the UX is what matters, regardless of attributes, protocols, etc.
And without UX, that is if you don't know what UX you want, you'll overdesign/overengineer your protocols & formats, as nearly all protocols & formats are.
On the IndieWeb, we focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest most minimal protocols sufficient to support that UX, and nothing more.
There are various design experiments which may be useful as sources of inspiration, or may indicate fleeting fashions or ephemeral design trends:
- parallax scrolling - use of scrolling to change perspective / layout of what is on the page, e.g.
- Anecdotal opinions from in-person conversations with web designers at Brooklyn Beta 2014 noted universally that parallax design was cheesy and to be avoided.
Articles about user-centered design and UX in the context of the Indie (social/federated) Web.
- 2017-10-06 'Our minds can be hijacked': the tech insiders who fear a smartphone dystopia - examples of dark silo designs that indieweb design could counter with designs that enhance personal focus, attention, and possibly even productivity, by help people shift from using silos to indieweb tools and services.
- 2013-06-10 Brad Frost: atomic web design
- 2015-08-11 Alla Kholmatova: The Language of Modular Design
- 2018-06-29 Fast Company: Why tech’s favorite color is making us all miserable (tl;dr: blue bad, orange/red good)