Improving WordCamp.org: User Experience of the CSS Editor

One of the discussions we had at the 2014 Community Summit was about customizing WordCamp.org sites, and we identified some of the worst pain-points that organizers currently have.

One of those problems was thatย customizing a themeโ€™s CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. is difficult and frustrating.ย Currently, organizers use Jetpackโ€™s CSS Editor, which works well for small tweaks, but isnโ€™t really intended for the types of major overhauls that most WordCamps are doing. Some of the biggest problems are:

  • There isnโ€™t any post-locking or version control, so itโ€™s easy for two users to accidentally overwrite each otherโ€™s changes
  • Saving edits requires a page refresh, which makes you lose your place. With larger rulesets, finding your place again takes too long and often breaks mental โ€œflowโ€, which is frustrating.
  • The browserโ€™s built-in Find functionality doesnโ€™t always work
  • The rules canโ€™t be modularized into small, manageable files โ€” and then recombined during processing โ€” for easier development and maintenance.
  • Many consider editing in a browser to be a subpar experience to using an IDE with features like code-completion
  • Cross-browser/device testing canโ€™t be easily done with the Preview functionality
  • Syncing between production and a local testing environment has to be done manually
  • Time-saving tools like LiveReload canโ€™t be used.
  • There are two scroll bars (one for the page itself, and then another inside the editor), which makes using the scroll wheel on a mouse annoying.

So,ย how do you think we shouldย move forward andย made it easier for organizers toย customize their themeโ€™s CSS?

#community-summit, #improving-wordcamp-org, #jetpack-css-editor, #official-websites, #user-experience, #wordcamp-org