Here’s something I come across in a lot of articles that I edit for SitePoint, and it’s a phrase that appears in many forms, but essentially boils down to two words:
“It’s easy.”
For those of us who have been building websites since the dawn of (internet) time, there are boatloads of things that are “easy”. But for many readers on SitePoint (and a lot of other websites), the things we write about are not easy. Even a single line of CSS can be difficult for some people.
This idea of assuming something is “easy” or “simple” calls to mind Brad Frost’s post from over a year ago on the Pastry Box Project, simply title “Just”. So yeah, even experienced, well-respected, and super-smart members of the community are alienated by terms that imply that something is a no-brainer. In fact, that’s exactly the kind of thing I was mocking in FAQ #2 of my fake JavaScript über-library.
So my advice to writers is always the same: You don’t have to tell your readers that something is “easy” or “simple”. Explain the context, the background, the technique, the steps involved (or whatever else you’re trying to communicate) — give as much detail as you need to give. If it’s “easy” to Developer A, he will decide. If it’s “simple” for Developer B, she will draw that conclusion. And developer C might think it’s totally over his head.
Let them decide. I think this is an important part of writing regularly. I believe this helps authors gain respect from a wide range of readers and is something that all developer-writers should work on improving.
There’s another bit to that that is almost universally missed - how to recover if one of the steps doesn’t go as expected.
For me, following HTML is no issue, though I’m still getting familiar with the newer tags in HTML5 and their associated attributes. CSS isn’t too hard to follow, though some of the stuff in CSS3 I’m yet to investigate. JavaScript I’m working on. PHP I’ll dip into only if I need to tweak something in my blog. MySQL, I can get round enough to survive. Frameworks and all the heavyweight stuff just goes right over my head though, and some of the concepts behind stringing it all together may as well be in Swahili at times. I’ll get there…
Great points, Louis. The ease or difficulty of any task often has a lot to do with one’s experience etc., which is different for everyone.
It’s also funny how people in forums often start by saying—“I have a really simple question that should be easy to answer”. Well, if it’s simple, why don’t you know the answer? Often the questions are actually very tricky to answer, too!
I think they tell it just for psychological reasons.
Many people afraid that new technologies are too complicated for them.
So, it’s often a good start to say “hey, it’s easy, look how it works”
Yes, I see that type of question often but strictly speaking simple and easy do not mean the same things:)
Years ago my Water Skiing instructor always used the phrase “It’s simple but it’s not easy”. There are only three main points to good slalom ski-ing and that is knees bent, back straight and arms straight. The concept is simple. However it’s not easy to do when being flung across bumpy water at 70mph.
Web design is a bit like that at times
Yes we should all take care that just because its easy for us doesn’t mean it will be easy for someone else.
Well written! This editorial targets exactly what I have been thinking over the past few months. When I go on the forums to read the threads and learn from those who are eager to help out, there are some who kindly explain the answer to a question and I find I respect their knowledge and expertise and look forward to reading more of what they have to say.
The ones who can’t resist making a point of saying the skill is easy (so why is the question even being asked) lose my respect very quickly - both for their answers to the question and for their background in the field.
Having taught for over 30 years, I can assure you that ’ It’s easy ’ as a response to someone who is having problem with a concept is not a reassurance to them that it is easy, but a put-down of the person asking the question and an ineffective attempt to elevate oneself in the eyes of others.
Take out those words, and see how informative and helpful the rest of the post can become. It doesn’t need the extra ‘window-dressing’ to impress the OP that the answer is coming from an expert in the field.
“Easy” is subjective - I find it easy to change a wheel on my car, it’s not rocket science but it’s not something everyone can do.
So rather that saying “easy” perhaps authors should be encouraged to specify a skill level required to do the task, eg Beginner, Intermediate, Advanced?
It’s hard to gauge a users skill level though. Take a CSS dropdown. Just because someone can do one, would you think they are intermediate? What if they don’t know anything else?
It’s just hard to objectively tell a users skill level sometimes. Not everyone follows a standard guide to learning languages, where they learn x first, then y, then z. They can go from b to d to g, and those who know x,y,z will think they are more advanced than the people who know b,d,g. Also I know that I would hae a hard time gauging what sort of skill level someone would need to do some different layouts or techniques.
Sounds nice but I’d like someone elses thoughts on this.
A general skill level description is probably too vague, perhaps it needs a bit more meat, eg “This tutorial requires a familiarity of CSS” - you get the idea?
Probably more specific than that. For my dropdown example, perhaps familiarity with position relative/absolute, z-index, and the coordinates (top/right/bottom/left.)
Familiarity with those properties / values will then show you how you can put all of those ingredients in a bowl and come out with your perfect cake (dropdown.)
I think I was in this boat… for example I’d say “Installing Windows is easy” but this was tremendous task for non-it folks. I still think it’s ok to say ‘It’s Easy’ if the author knows the audience well. If the audience is so general then I agree with the Ops. Look at the success of ‘book for dummies’, the whole concept is to convey ‘It’s Easy’.
I couldn’t agree more. I have been working with the web for a really long time. I am 70 now and retired. I have programmed in assembly, C, C++, PHP, perl, python … Really too may languages to remember. I went to UCLA when we still used slide rules and submitted our programs on a stack of Halaruth cards.
I think I am pretty savvy and have an in depth background BUT a lot of articles on the web leave out so many important pieces of information that they are simply NOT simple. A case in point was my experience yesterday with React. I followed a link from a SitePoint article to the React GitHub Starter Kit. All went well until I got to the point where I was supposed to look at the results on the browser. Nowhere does the documentation mention what localhost port to use. I had to crawl through their esoteric and not well commented source code to find the answer – NOT SIMPLE OR EASY. All it would have taken was a one liner that said “Enter localhost:xxxx into your browser”.
Unfortunately my React experience is not unusual on the web. There are way too many things left to the imagination. Most people are not physik and can not read the mind of the author. As the saying goes “The devil is in the details” and it is those details that should not be left out.
If you are reading a tutorial… it’s likely because you don’t know how to do it. Often people are pressed into doing a job slightly outside the area they normally operate in, or they are looking to expand. Consider the audience and try to anticipate their questions.
If it was truly just simple and easy, we’d all be out of jobs!
I hate when people start sentences with Just. Especially people people whom aren’t engineers or know very little about the context of a problem. I have to say though I’m not alienated by tutorials or articles which lack details about dependencies/prerequisites. Typically there is enough available on the internet to go figure any prerequisites out myself. When it comes to many modern dev technologies it is likely that many writers don’t even know much about the technologies they are using except for the fact they were able to install it. A front-end developer writing about sass or grunt might not really be equipped to tell you how to install those things on a particular machine or set-up as an example.
Great point, Louis! It’s ‘easy’ to drop an ‘easy’ or ‘simple’ here and there into a tutorial without even realizing it.
Because, as Ryan has pointed out, it’s hard to gauge the readers’ level of experience, let’s be more aware of our language and avoid using those prejudicial expressions.
However, just playing devil’s advocate here, developers often come across clients who ask for this or that ‘small, easy job’ on their website, something that shouldn’t take long or that they would do themselves if they had the time, etc. It could be that, perhaps, hearing this sort of thing too many times, might lead devs and web designers sometimes to forget about how much of what they do is actually not so easy and left to improvisation as some unfortunately think.
. I think I’m guilty of this…