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.

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

19. Focused Uberbar
Navigation Opens
🔎

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
🤘

23. HTML5 ContextMenus

24. HTML5 ContextMenus

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
😎

31. VoiceOver Support
🤘

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)
👀

34. High Contrast Modes
👀

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

37. Progressively Enhanced
Iconography
120kB0kB

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
🎨

45. CSS Variables
accessible theming
🎨

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
🤘

52. Actively Developed
github.com/jpdevries/m5bp
m5bp.herokuapp.com
⚒

53. 👻
Emoji–first Iconography
VoiceOver friendly

54. Cross Browser

55. Cross Browser

56. Cross Browser

57. Cross Browser