Architecting a Futuristic MODX Manager with HTML5
2 likes257 views
The document proposes design principles for a new version of MODX focused on accessibility, inclusiveness, and progressive enhancement. Key points include making the interface mobile-first, HTML-first, and progressively enhanced using semantic markup, CSS variables for theming, and emoji-first iconography to keep file sizes small. The goals are to empower developers with creative freedom, optimize the user experience through search and accessibility features, and ensure the interface is usable by everyone across various abilities and devices.
Architecting a Futuristic MODX Manager with HTML5
- 1. M5BP architecting a futuristic MODX Manager with HTML5
- 2. MODX 2.X • Desktop First (inline styling, non–responsive) • HTML Last (ExtJS owns the DOM) • Ableism (mouse reliance, non-semantic markup) • Aggressively Enhanced (white screen of death, 🚫 HTML) 😶
- 3. • Desktop First (inline styling, non–responsive) • HTML Last (ExtJS owns the DOM) • Ableism (mouse reliance) • Aggressively Enhanced (white screen of death, 🚫 HTML) • Really Awesome (creative freedom, community) 😁 MODX 2.X
- 4. • By tracing our technology stack back to web standards we allow creative freedom in how it is progressively enhanced thereafter • Extra Developers can use the tools of their choice (a less opinionated API) • Themes configurable via CSS Variables makes theming more accessible 🎨 Creative Freedom
- 5. • mouse enabled • sighted • abled • desktop • sufficient data 🏃 Current Audience restricting access 2.X
- 6. • touch • non-sighted • disabled • mobile • cellular 🌐 Wider Audience let everyone in the building 2.X 4.X • everyone
- 7. Design Patterns • Mobile first (viewport, touch, bandwidth, battery) • HTML–first (semantic, accessible, future–forward) • Inclusively Designed (assistive tech, a11y preferences) • Progressively Enhanced (interpretative, configurable) • Searchable (filterable interface, search mode) 🙏
- 8. Primary Goals • Creative Freedom (empowering developers) • Count the “Clicks” (monetize user experience) • Everything in Reach (search everything a tap away) • WCAG 2.0 Level AA (accessibility compliance level) • VoiceOver Support (screen reader support, hidden text) 🙏
- 9. mobile first sticky bamboo • A single tall scrollable column • Collapsable sections (<details>) • Sticky bar with jump to links Anywhere is within reach 📱
- 10. HTML–first • Initially working within the limitations of HTML makes for a more performant design • Design challenges are solved semantically before visually styled or asynchronously enhanced <form action> • Low ARIA usage ARIA is Salt 👆
- 11. • HTML is interpretive • JavaScript is declarative • A semantic HTML document improves with time • An non-semantic declarative document decays with time 👆 HTML–first
- 12. “Not including accessibility from the beginning is implicit consent to incurring technical debt.” —Karl Groves tenon.io 📉
- 13. Technical Debt vs Profit
- 14. Searchable • MODX Revolution introduced the beloved uberbar 🎭 • Imagine taking the uberbar to the interface level 🤔 🔎
- 15. • Shortcuts to fully expand / collapse <details> ⚡ • CTRL+OPTION+SHIFT+⬆ • CTRL+OPTION+SHIFT+⬇ 🔎 Searchable
- 16. • Compatible with native browser search features 👏 • URL friendly /#uber?q=kansas 🔎 Searchable
- 17. Search Mode Entire Interface Opens 🔎
- 18. Desktop Uberbar 🔎 • Entire nav expands on :focus • Can scroll passed it • Dynamically filtered
- 20. “Try to refrain from allowing ableism into your designs. Spend the same amount of time you spend on visual styles on accessibility. #A11Y” —@mrktps markup.tips ⏰😎
- 21. Inclusively Designed Not a single critical features relies entirely on: • vision • style • mouse • script 🤘
- 22. Inclusively Designed • Enhancements are withheld until they’ve been architected accessibly • In other words, critical features exclusive to mouse users are not added until they are compatible with assistive technology • This often leads to discoveries otherwise left unfound 🤘
- 25. Future Forward ready for a new precedent • Writing future forward code isn’t just about supporting future browsers • It is also about supporting more inclusive future societies such as Germany • Companies with more than 20 employees are supposed to fill at least 5 percent of their positions with people with disabilities 🔮
- 26. Keyboard Friendly • Uses an accessible design pattern discovered as part of a manage users concept • no right click • no modals ⌨
- 27. Battery Friendly • Follow the MAB Responding to Battery Levels DRAFT • Components switch between glutenous, modest, and fasting CPU consumption modes • A more efficient interface is a more accessible interface (as it can be used longer) 🔋
- 28. Audible Profile (what’s the interface sound like?) Not only is the interface tested cross–browser for visual styles, an audible profile ensures the interface is semantic and usable for all users. Like salt, ARIA is generally avoided and used in measured doses as a final seasoning if needed. 📣
- 29. Screen Reader Friendly Visually Hidden text audibly conveys what is otherwise conveyed visually to sighted users 😎
- 30. HTML–first (look MOM, no AIRA) Text is hidden with CSS so that when the CSS is removed, and the correlation between styled components is lost, the text appears 😎
- 32. VoiceOver Support (jump links accessible to keyboard & screen reader) 🤘
- 33. High Contrast Modes • Accessible CSS supports white-on-black and black- on-white contrast modes • Configurable by Operating or MODX System Settings (not a separate manager theme) 👀
- 35. Progressively Enhanced • Starting HTML–first means starting interpretative first • System Fonts, Emoji Icons, & modern browser features are weightless • Make use of everything we can already on the device before spending on web fonts, icon sets, and scripts 🐣
- 36. • as enhancements are made make them configurable so they can be opted out of or altered • For example, icon sets can be opted out of and the interface falls back to emoji • heavy web fonts are opt in 🐣 Progressively Enhanced
- 38. Emoji Art is already there
- 39. • Emoji art weighs 0kB and is inherently accessible 📦 • Emoji is the fasted growing language 📈 • Icons improve legibility 👓 👻 Emoji–first Iconography
- 40. • Is interpretive 🎭 • Will look different from system to system 😭 • Can be progressively enhanced (SVG, fontawesome, whatever) 🚀 👾 Emoji–first Iconography
- 41. • Assumptions of ability are not made based detected peripherals or assistive technology • Not all screen reader users are legally blind or even visually impaired • i18n is easy to find 👥 Inclusively Designed
- 42. CSS Variables 🎨 • Append a stylesheet or <style> which sets CSS Variables to customize values • WYSIWYG tools could allow end users to customize the styles without writing any code 🤔
- 43. CSS Variables 🎨
- 44. CSS Variables 🎨
- 46. Accessible Theming • No longer is an ExtJS, Sass, Grunt skillset needed to paint the Manager • No knowledge of CSS selectors needed • As accessible as setting a few CSS variables • *Variables can be adjusted WYSIWYG at the user level in Accessibly Preferences (*WIP) 🎨
- 47. Count the “Clicks” • Each feature has a cost spent in measurable user interactions such as clicks and key presses • Persistent uber and jump bars keep search everything always within reach 🖱
- 48. • Important features accessible via VoiceOver rotor ⌨ Count the “Clicks”
- 49. Weigh In • Current baseline weight is 20kB including the example HTML document weight • 5kB CSS • 6kB JavaScript • Interpretive Code is already on the device 🏋
- 50. Spending Bytes • Additional declarative enhancements such as webfonts can be configured to load • Allow users to opt-in to expensive features (eg: default to emoji icons option for fontawesome) • save-data when asked to 💰
- 51. Freedom of the DOM • No library or framework owns the DOM 🤘
- 54. Cross Browser
- 55. Cross Browser
- 56. Cross Browser
- 57. Cross Browser