Mozilla Hacks

Web Design Survey Findings and Next Steps

Avatar photo By Victoria Wang

Posted on February 20, 2019 in CSS, Developer Tools, Featured Article, Firefox, and Survey

In November, I wrote about my team’s work on experimental new web design tools. We also ran a survey to rank the challenges of web design and development. A big thank you to everyone who participated in our open design process! We received over 900 responses in one month, and discovered major findings which continue to inform the Firefox DevTools’ 2019 roadmap.

The Methods

With guidance from Mozilla’s data scientists, I chose the MaxDiff method for the challenge-ranking portion of the survey. MaxDiff requires the survey taker to make trade-offs within subsets of the pool of options. This works well for ranking a large number of options, which would be too overwhelming for a regular card sort. It also produces a more accurate overall ranking by emphasizing relative differences in priority.

In practice, this produced 10 survey pages that each showed a set of 4 random options from a pool of 23 total web design challenges. Participants had to choose the “least“ and “most” impactful options in each set. The ranking was then determined by scores computed using the following formula:

# times rated best – # times rated worst
—————————————————
# times item appeared

The second portion of the survey focused on specific frustrations with browser developer tools. For this section we only offered 7 options, so we used a simple drag-and-drop card sort.

The Takeaways

Survey MaxDiff results

The highest-ranked issues by far were related to CSS layout debugging—learning the root cause of mysteries like unwanted scrollbars and unexpected size and position. Accordingly, my highest priority right now is digging deeper into CSS debugging issues with further research and experiments. (You can help by taking my brief new CSS Debugging follow-up survey! More info below.)

Unsurprisingly, cross-browser compatibility was also a top choice. We’re investigating ways to ease the pain of debugging browser differences, including auditing, hints, and a more robust responsive design tool.

Mid-ranked issues included Flexbox, Grid, and Accessibility. We plan to continue improving our Accessibility Panel; however, for now we’ll step back a bit from our successfully launched Flexbox and Grid tools. Letting them breathe and collecting more real-world feedback will allow us to swing back with fresh new ideas later.

Lowest-ranked issues included Lack of Visual/WYSIWYG Tools, Animations, WebGL, and SVG. The visual tools part was surprising—we’ve seen a lot of love for click-and-drag visual tools like the beautifully designed Visbug and Webflow. I suspect my old-school wording here—WYSIWYG (“what you see is what you get”)—brought to mind less-delightful experiences of the past. There are clearly ways to improve developers’ lives with modern tools in this space.

As for the browser issues card sort, we hear you loud and clear on the issue of “Moving CSS changes back to my editor.” We’re currently in the process of adding export options to our Changes panel, and would love your input on our designs! DOM breakpoints are also in the plans for this year.

You can view the full MaxDiff and card sort rankings in this report.

Follow-up Survey: CSS Layout Debugging

Banner: Help us build better CSS Tools! Take the survey

Now we need your help again! The main takeaway from the first survey was that developers and designers of every experience level want to better understand CSS issues like unexpected scrollbars and sizing. We’ve started researching and prototyping potential tool ideas for investigating specific types of CSS bugs, but we need your feedback to guide our work.

Please take a moment with our quick single-page CSS Layout Debugging survey and help us rank the most time-consuming bugs. Your feedback will be immensely helpful in clarifying our plans in 2019 and beyond.

Thank you!

Victoria & the Firefox DevTools team

About Victoria Wang

Victoria is a Portland-based UX designer at Mozilla who works on Firefox DevTools.

More articles by Victoria Wang…

8 comments

  1. Oenonono

    It’s because visual tools have different strengths and weaknesses than code. We have literally decades of drag and drop visual UI builders for a variety of platforms and not a single one of them has done away with code or even approached the scale of success of HTML and CSS, two languages designed for non-programmers. No one thinks it’s strange that we have graphics, prose, and math. No one suggests we rid ourselves of math or the written word because clearly pictures are easier to deal with for more people. No one suggests it’s a “waste” of our time making math, reading, and writing easier to teach and learn, more approachable, more accessible. Which makes it all the more funny that you’re rationalizing away your own data–obviously if WYSIWYGs aren’t as popular an idea as you expect, it’s your phrasing that led to bad answers tainted by past experiences. Please entertain the idea that those past experiences informed the answers exactly the way experiences *should*. Why is it so hard to accept that barring some breakthrough no one’s had yet, new efforts to replace hand-written UX code with WYSIWYGs will be about as worthwhile as old efforts? That’s not to say, “none,” but just “some.” Some limited usefulness, but often required to be purpose-built for both a particular design system and platform, leading to their having the life expectancy of a butterfly, and needing both an understanding of the code they generate as well as the ability to write code to supplement the strictly limited affordances of a drag and drop, point and click GUI. Particularly the way all those limits also limit the ability of a designer to be creative, to invent new interaction patterns… There’s a reason why some designers were so psyched about learning to code and designing in the browser and a reason why so many of those very same designers have made incredibly valuable contributions back to the web platform. They didn’t have to try to convince an engineer to be interested enough to really dig in and figure out how to make a design work or sell the idea that it’s a better use of time to master what the web platform can already do sufficiently to realize design possibilities that other engineers would simply say are impossible, rather than working to impress those very same naysayers by pushing a TypeScript agenda. I used to love that work so much, but I can’t remember the last time I was able to do it. Instead I am forced to waste my time with transpilers and arguments over frameworks. The best thing Mozilla could do would be to work to give this platform back to the people who made it grow, to give some space in it back to designers, copywriters, and non-traditional developers.

    February 20th, 2019 at 19:47

    1. Victoria Wang

      I didn’t intend to rationalize – just keeping an open mind considering the interest in modern visual tools. We aren’t planning anything in this space for reasons similar to what you mention.

      February 21st, 2019 at 10:53

  2. RIPON Mohammed

    Thanks for consideration

    February 21st, 2019 at 09:28

  3. Jake Pogorelec

    You know what else could be useful as a tool for CSS debugging? Being able to see CSS for state related properties easier. Like if you looking at a “a” link element property, there could be some sort of selection drop down giving you the opportunity to see that same element under “:hover”, “:visited”, etc states. Ever try to see a hover state style but it keeps disappearing from the inspector rules? Its a pain.

    February 21st, 2019 at 10:28

    1. Victoria Wang

      Thanks, will make a note of this idea!

      February 21st, 2019 at 10:54

    2. Matt

      You already can. In the css panel of the inspector there’s an option next to filter to turn on pseudo classes, and it will show the element with that style, the pseudo class highlighted in the css panel, and the parent elements highlighted in the inspector panel.

      February 23rd, 2019 at 01:25

  4. jop

    My biggest CSS problem inevitably comes from spending 11 minutes figuring out why none of my grid properties are applying to this grid-template container, checking syntax, gaps, margins, inheritance and more only to realize I never actually specified display: grid to begin with

    February 21st, 2019 at 10:30

    1. Victoria Wang

      Thanks – we have some ideas for addressing this kind of problem.

      February 21st, 2019 at 10:55

Comments are closed for this article.