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