design(Redirected from Design)
✂ This article is a stub. You can help the IndieWebCamp wiki by expanding it.
Design is a catchall term used to refer to everything that affects users about a page/site including:
Thoughts
Some thoughts on design. MinimalismWhat'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 UseOnce 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) IncrementalIt'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 InfrastructureThere is a misdirected priority/desire (often among developers/engineers) for things like:
"...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 ProtocolsStart 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.[2] ScreenshotsSee specific features (e.g. from IndieMark) and building blocks for screenshots and to add more, e.g.
ExperimentsThere are various design experiments which may be useful as sources of inspiration, or may indicate fleeting fashions or ephemeral design trends:
ArticlesArticles about user-centered design and UX in the context of the Indie (social/federated) Web.
See Also |



















