As a designer trying to learn coding, I’m surprised by how the UX of the coding activity itself is not built to set us up for success.
The developer experience of coding is broken. As a designer trying to learn coding, I’m surprised by how the UX of the coding activity itself is not built to set us up for success.
A designer's perspective on the experience of coding
In design, we have this thing called bodystorming. Basically, if you have an idea for a new product/service or improvements to an existing one, rather than talk in the abstract about it and imagine how it would be like, you get up, get out and try it out with your own body.
Bodystorming is the act of physically experiencing a situation in order to immerse oneself fully in the users’ environment, in order to develop empathetic understanding of the painpoints and high points that users face.
It’s a technique that’s similar to what consumer/marketing research calls mystery shopping. As a designer myself, it had become second nature to constantly observe and evaluate how I can design better experiences while experiencing the thing itself. Call it an occupational hazard.
So that’s what I found myself doing while learning how to do programming (mainly front-end web development using HTML, CSS and JS). I was bodystorming the activity we call coding. And boy, does the user experience of coding feel broken. As someone new to it, there’s things we do in coding that just bewildering to me. One thing is the way we code and check our work.
The UX of writing and checking code is broken
I don’t particularly enjoy the workflow of writing code on the text editor and refreshing the browser page to see if the page turned out as you wanted it. What happens is very often you go back and forth between 2 or more screens - the text editor and the browser - tweaking tiny changes until everything lines up the way you want it.
It’s like we’re trying to paint a Picasso, but writing down extremely detailed and specific text instructions to micro-manage someone else to paint it for us, down to the angle of how they hold the brush, how many strokes of a specific colour to dab on, at which specific millimetre square of the canvas. Just that in the case of coding, the painting is the website, that someone else is the computer, and text instruction the code. It’s the wrong way round! If I need to do spatial layouts on a web page, I do it right there on the browser, by drawing the shapes or placing the elements where I want them, spatially. Not type text! Typing text to do that is a counterintuitive to a human user and sets up an additional layer of complexity and difficulty to achieving what you want. Visual and spatial work should have visual and spatial tools, not text. It was frustrating having to learn coding using such tools, when as a designer I’m used to using tools like Sketch and Photoshop.
A visual way to code is more human-centered
The tools we have now for coding are mostly computer-centric, not human-centred. What I need is to code a website, visually.
I later learned that there are tools like Pinegrow and Webflow that allows you to do just that - drag-and-drop a website together visually, while the auto-generating clean and semantic code for you to be exported. Thank god! But that made me even more confused:
If such tools are available, why are we still learning/doing (front-end) development the old way?!
Why aren’t these tools more popular and commonly used?
In fact, if we can do it this way, what’s the value of learning the syntax then?
Caveat though: I’m only at front-end web development (HTML, CSS, JS) so far. I can’t speak for the experience of doing back-end development, whether it’s broken too, etc. More learnings to come!
Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.
Top comments (18)
This is common for people who are new to programming. It's a mental shift.
This is exactly what it is. It's telling a computer to parse instructions.
The thing is, those programs are also written with the same type of
key:valuebased text files. They are also code. Beyond that, they are generally static. They are not flexible living design systems. They cannot do what The Web does.Fiddling around with a bunch of panels that disappear and all use different language to describe styles / even when using some of the better systems - isn't very human either.
CSS allows us to design rich systems in a completely different way from raster-based image programs like Photoshop. Designing these systems / with text / in an editor / is faster than learning a WebFlow like program - and it's much more direct and clean. Run a lighthouse score on a Dreamweaver or Webflow project. It's been a valiant effort since 1997, but - in all too many ways - more effort than learning HTML and CSS (which is really easier than ever right now).
In the future, we probably won't use screens as we think of them today. XML and HTML are really about structured data. Even now, we search pages with Alexa and Siri. The "Look" of things that you are calling design - is only a surface level.
It's a natural process to go through this. Enjoy it! Watch the Webflow videos about Grid. They are really charming - but a total nightmare:
Instead of learning to declare the styles in a clean and concise way - you'll be learning Webflow (which will surely go away). Beyond that, you'll be missing out on the data and content strategy layer.
Nah I disagree. Webflow is here to stay. Not everyone wants to learn frontend development done the professional way, and tools like Webflow is a great 'prosumer' kind of tool for these people. I had since learned frontend dev and got used to toggling windows, refreshing browsers, writing CSS etc, but to me the UX still sucks. There's still is much room for a better designed development experience.
Btw, fiddling with a bunch of panels that disappear might not be ideal, but that's still a much more visual way and a way better experience than making changes in your code editor.
“… Not everyone wants to learn frontend development done the professional way …”
The “professional way” is a highly subjective precept. It all depends on the prevailing convention and how many are actively using the design tools.
The tools are good starting points for learning and for designing “simple” projects for which the design tools are intended.
As the project grows in complexity, the tools are inevitably discarded.
Agree that conventions are subjective and do change.
But I don't think tools like Webflow are just starting points and to be eventually discarded. I seen many makers stick with using these tools even when they can code. In the end it's a preference and subjective, like you mentioned earlier.
Many devs think visual tools are just for beginners, like training wheels for kids' bicycles. I think there's a group who continue to enjoy using it and want to keep using it out of intention and choice.
I agree with your last paragraph — which was the intent of my last two paragraphs, which I think you misunderstood.
… The tools are good starting points for learning and for designing “simple” projects for which the design tools are intended.
As the project grows in complexity, the tools are inevitably discarded.…
The “discarding” is inevitably caused to the tool’s inability to meet the complexity of a project. Not because the tool is viewed as a “toy”.
Those tools are always useful for creating initial designs. And as design tools or any IDEs, they have their own limitations that one has to be mindful of.
Yes, it's only logical to switch if it no longer fulfils its purpose.
Ain't that the truth.
I'm excited to see what you come up with! :)
I think the future is already here, just not evenly distributed yet. Beginning to see drag and drop, templates website builders for specific frontend framework, like React. Drag drop, design in an entirely visual way without code, then export in React. Perfect.
If you see drag and drop as the future, then we've already been in the future since 1997. I built things with Dreamweaver in Highschool / and Flash in college - and thought "HTML is over" - and well, I was super wrong. And that's OK.
I see the surface level of that type of stuff as only 1/10th of the design process. If your goal is to learn web development the not professional way - or to become a data entry specialist, then this will be great for those people. If it's just dragging a few boxes around to make the same 7 layout compoents that 99% of sites use, then they wont even need that type of designer anymore. Hubspot and 30 other companies already have that system. Just pick a few out, change the words - and you have another innefective langing page to throw on the pile.
It's OK to dissagree.
But, you're right. Most websites - aren't large long-lived design systems. They can just get dragged around and it's not really going to matter if they are good or bad. Most of them are just there. I'm more interested in serious projects / with big ideas. Funny story: I once made a website for a pretty big animation studio. They were terrible clients. Months and months went by and they couldn't really figure out how to sign off on what we where showing them. They cound't figure out how to sign in. The boss was just having their assistant deal with it - so, instead of asking for the password - she just build them a website in Tumblr. Free! Even though they sill paid us 20k for our time. It was 1/10th as "cool" and robust... but - it seems to work just fine for them.
Yep. I think the sooner we devs realise that not everyone wants or cares about whether it's done in a professional way according to best practices that only devs care about, the sooner we can add value to businesses.
As mentioned on your other post - I've been thinking about this post since I saw it yesterday, trying to figure out why exactly it's hard to wrap my brain around visual -> code being the natural workflow.
To create my own analogy presenting code -> visual as the natural progression, I imagine code as a recipe rather than a painting. With a painting we are creating a single finished product, but with a recipe we are creating a way to communicate to anyone that wants to recreate our creation to be able to.
Consider that all screen sizes are different for our users. This is similar to when someone slightly modifies the recipe and ends up with a slightly different result than we may have imagined when creating the site. Our initial intended screen size might be the Gordon Ramsay version of our dish, but someone using our desktop site on their phone is the recreation at home by an average home chef. Every device with a browser is waiting for our latest recipe so they can enjoy it from home.
YES.
Interesting analogy about coding as cooking! I actually wrote something about it before!
dev.to/jasonleowsg/coding-is-like-...
This is a big pain point, and that's where tools like Live Server come in - It won't necessarily help much if you have a single screen you're working on, but it helps if you have screen real estate to show the code window and browser window at the same time. :)
There are many cases where you do not want your website to refresh (send a new HTTP request.) - so, it depends. But there are tons of solutions for that for each editor.
Maybe. So far not hit any of those rare edge cases. If I make a change I would want to check it immediately 99.9% of the time.
Thanks for the tool! Will check it out!
Webflow and Pinegrow are rather new tools to the market, and personally as a dev for at least a year, I haven't touched either of these tools yet 😂 it won't feel like a coding process if I were to use those tho, and in production/many companies we usually use frontend frameworks to build web apps.
For backend sometimes it's worse because sometimes restarting the server, migrating stuff tend to take longer for it to reload changes.