Things

Things not to say on stage at a tech event

cringing woman

This is also available on Medium

This is not about a post about trigger words or discriminatory expressions. There is a lot of information about this available, and even some excellent linting tools for your texts. It is also not about unconscious bias. Or well, maybe it is. Learned bias for sure.

This is a post about some sentences used in technical presentations that sound encouraging. In reality they may exclude people in the audience and make them feel bad about their level of knowledge. These are the following sentences and I’ll explain in detail how to replace them with something less destructive:

None of these are a show-stopper and make you a terrible presenter. There may even be ways to use them that are not confusing and destructive. This is language, and in some cultures they may be OK to use. I’m not here to tell people off. I am here to make you aware that something that sounds good might make people feel bad. And that’s not what we’re here for as presenters.

As a presenter your job is not only to give out technical information. You also need to inspire and to entertain. Often you overshoot the mark by simplifying things and trying to hard to please.

It is important to remind ourselves that we can not assume much of our audience. The room might be full of experts, but the video recording is also going out to everybody. Explaining things in a simple fashion is not dumbing them down. It may actually be the hardest task there is for a presenter.

It is stressful to be at an expert event. As an audience member you don’t want to appear less able than others. As a presenter, it is worse. Presenting is a balancing act. You neither want to sound condescending, overload the audience, make people feel stupid, appear too basic … and, and, and…

I’ve heard the following expressions at a lot of events and I always cringed a bit. Often they are OK, and no harm done. But,to improve as presenters it may be a good idea to be more conscious about what we do and what effects it can have.

“This is easy…”

We often try to calm down the audience by making what we show appear simple. The problem with that is that what is simple for us might still be confusing to the people in the room. Add peer-pressure to that and people will neither speak up that they don’t understand, nor feel empowered. The opposite applies – by saying something is easy and people failing to grasp or apply it, we make them feel stupid. If you make me feel stupid, you may inspire me to get better. But I don’t do it for the right reason – I do it out of guilt and self-doubt.

The worst way to use “this is easy” is when you rely on a lot of abstractions or tools to achieve the easy bit. Each of those could be a stumbling block for people applying your wisdom.

Replacements:

  • “Here are a few steps how to achieve this…”
  • “By using these tools, which are all well documented, you can…”
  • “The way to get this done is…”

Using these you send people on a journey. They don’t tell them that the end result is already a given. Who knows, they may find a way to improve your “easy” one.

“I’ll repeat quickly, for the few of you who don’t know…”

This expression just fell at a conference I attended and it made me cringe. The presenter meant to be encouraging in a “hey, we all are already on board” way, but it can come across as arrogant. Even worse, it already singles out those who do not know, and makes them feel like they are under a spotlight.

If the intention is to do a quick intro on what you want to build upon, it is better to phrase it as a reminder, not a “you already know, what am I doing here”.

Replacements

  • “Just as a reminder, here is what $x is about…”
  • “As you may remember, $x is about…”
  • “We’re building this using $x, which is…”

This adds your repetition into the flow instead of being an excuse.

“Everybody can do that…”

If everybody can do it, why do I listen to you? Also, if everybody can do it, how come I never managed to? If you use this you either present something basic, or you over-simplify a complex matter. The latter can appear to be empowering; you take away the fear of approaching something. But, it backfires when people can’t use it. Then you exclude them from “everybody”. And that hurts.

Replacements:

  • “If you know your way around $x, $y and $z, you should find it easy to…”
  • “Once you managed to do that, you’ll find it makes the rest of your work easier…”
  • “It is a very effective way to work, if it works for you, tell others about it”

This again makes it a reminder and a starting point of a journey. Not a given that is redundant to repeat.

“$x solves this problem, so you don’t have to worry about it”

Hooray for your product – it solves everything. Now buy it and impress people with wisdom you don’t have. And feel worse when you get praised for it. This is a classic sales pitch which works with end user products. As a developer you should always worry about what you use in your products as each part can become an issue. And it will be up to you to fix it.

Replacements

  • “$x solves the problems around $y, so you can build $z”
  • “$x was created to make $y easier and is used in production, the results are encouraging…”
  • “Here are the steps you can do by hand that $x does for you…”

Pop open the hood, show how your product works. Don’t sell all-healing remedies.

“As everybody knows…”

Common knowledge is a myth and relies on your environment, access to information, time to consume news and the way you learn. Presenting something as common knowledge may make people think “so how come I ever heard of it?” and stop them in their tracks.

Replacements:

  • “This has been around for a while and was explained wonderfully in $x ($x being a resource you link to)”
  • “Tests have shown that $x is a given for a lot of solutions (point to research, give proof)”
  • “I base this on the fact that $x, as proven many times by… (and add a list a resources)”

“Citation needed” is a wonderful way to say something and prove your point. You show people that you did your homework before you make an assumption. And you give those who did not the tools to do so.

“This is just like we learned in school…”

This assumes everybody went to a school with the same curriculum as you. A lot of people have not. This is especially destructive when it applies to knowledge that was part of a Computer Science degree.

Replacements:

  • “This has been part of Computer Science teaching for years, and for good reason because $x”
  • “This should look familiar to anyone who went to a similar school as me, and for those who didn’t, there’s truckloads of information available online about it”
  • “You might remember this from school – now you see how it can be applied in a real job. Who knew?”

A lot of people create the web. Not all took the official path.

“That’s why $y(your product) is much better than (competitor) $x”

This is common in advertising, especially in America. You show off your product by making others look worse. This is pointless and only invites criticism and retaliation by others. As a tech presenter, you should know that the other product is also built by people. Final decision of what gets shipped are not always based on technical merit. It is a cheap shot.

Replacements:

  • “Here’s how to do that with product $x, we took a different path and here’s why…”
  • “There are many solutions to this. We found that some were lacking a feature that made us more effective, which is $x”
  • “You can use whatever makes you happy to achieve $x. We added the following, as we found it was missing…”

Showing you know about your competition prevents questions about it. Showing how they differ allows people to make up their mind which is better instead of you telling them and hoping they agree.

“This can be done in a few lines of code…”

The amount of code has become a contrived way of showing how effective our solutions are. Almost always the “quick and small solution” blossoms into a much larger one once it is used in production. It makes much more pragmatic sense to tell people that this is inevitable, and praise the small starting point for what it is – a start.

Replacements:

  • “As you can see, starting this is a few lines of code. I simplified this to show here, the source code is available at $x”
  • “For now, this is all that is needed to achieve this. No doubt, you will need to add more to it, but it is a starting point”
  • “By abstracting some of the issues out, we can cut down our code to a few lines”
  • “As we rely on functionality of $x, this means our implementation can be very small…”

A lot of times, this solves our own issue of showing only a few lines of code on a slide. Instead, let’s write understandable code that we explain in sections rather than one magical tidbit.

“If you want to be professional, do $x”

People have different opinions what a “professional” is. Whilst we worry about quality and maintenance, other people put more merit on fast delivery. The state of the art changes all the time, and a sentence like this can look silly in a few weeks.

Replacements:

  • “$x, $y and $z are using this heavily to deliver their products. Here are some case studies that show the positive results…”
  • “Using $x gives you a starting point you can rely on and makes it easier to explain to your replacement how to take over the product…”
  • “The benefits of $x are $y, which makes it a professional tool to use…”

You achieve professionalism with experience and by learning about new thing and retaining them. Things people say on stage and define as “best practice” need validation by professionals. It is not up to you as a presenter to define that.

A quick check

There are more unintentional destructive expressions. Read through your talks and watch your videos and then ask yourself: “how would I feel listening to this if I didn’t know what I know?”. Then remove or rephrase accordingly.

Our market grew as fast as it did by being non-discriminatory of background or level of education. Granted, most of us grew up in safe environments and were lucky enough to have free schooling. But there are a lot of people in our midst who came from nowhere or at least nowhere near computer science. And they do great work. I’d go so far as to say that the diversity of backgrounds made the web what it is now: a beautiful mess that keeps evolving into who knows what. It is anything but boring. There is never “one way” to reach a goal. We discovered a lot of our solutions by celebrating different points of view.

Photo by alyona_fedotova

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

All the small things at Awwwards Amsterdam

Last week, I cut my holiday in the Bahamas short to go to the Awwwards conference in Amsterdam and deliver yet another fire and brimstone talk about performance and considering people outside of our sphere of influence.

me at awwwardsPhoto by Trine Falbe

The slides are on SlideShare:

The screencast of the talk is on YouTube:

I want to thank the organisers for allowing me to vent a bit and I was surprised to get a lot of good feedback from the audience. Whilst the conference, understandably, is very focused on design and being on the bleeding edge, some of the points I made hit home with a lot of people.

Especially the mention of Project Oxford and its possible implementations in CMS got a lot of interest, and I’m planning to write a larger article for Smashing Magazine on this soon.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

All things open talk: The ES6 Conundrum (slides/screencast/links)

I just delivered a talk on JavaScript and ES6 at All things Open in Raleigh, North Carolina.

This is just a quick post to give you all the content and links I talked about.

Here’s the slidedeck on Slideshare

And the screencast of the talk on YouTube

Links I mentioned:

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Slimming down the web: Remove code to fix things, don’t add the “clever” thing

Today we saw a new, interesting service called Does it work on Edge? which allows you to enter a URL, and get that URL rendered in Microsoft Edge. It also gives you a report in case there are issues with your HTML or CSS that are troublesome for Edge (much like Microsoft’s own service does). In most cases, this will be browser-specific code like prefixed CSS. All in all this is a great service, one of many that make our lives as developers very easy.

If you release something on the web, you get feedback. When I tweeted enthusiastically about the service, one of the answers was by @jlbruno, who was concerned about the form not being keyboard accessible.

The reason for this is simple: the form on the site itself is none insofar there is no submit button of any kind. The button in the page is a anchor pointing nowhere and the input element itself has a keypress event attached to it (even inline):

screenshot of the page source codeclick for bigger

There’s also another anchor that points nowhere that is a loading message with a display of none. Once you click the first one, this one gets a display of block and replaces the original link visually. This is great UX – telling you something is going on – but it only really works when I can see it. It also gives me a link element that does nothing.

Once the complaint got heard, the developers of the site took action and added an autofocus attribute to the input field, and proudly announcing that now the form is keyboard accessible.

Now, I am not having a go here at the developers of the site. I am more concerned that this is pretty much the state of web development we have right now:

  • The visual outcome of our tools is the most important aspect – make it look good across all platforms, no matter how.
  • As developers, we most likely are abled individuals with great computers and fast connections. Our machines execute JavaScript reliably and we use a trackpad or mouse.
  • When something goes wrong, we don’t analyse what the issue is, but instead we look for a tool that solves the issue for us – the fancier that tool is, the better

How can this be keyboard accessible?

In this case, the whole construct is far too complex for the job at hand. If you want to create something like this and make it accessible to keyboard and mouse users alike, the course of action is simple:

  • Use a form elment with an input element and a submit button

Use the REST URL of your service (which I very much assume this product has) as the action and re-render the page when it is done.

If you want to get fancy and not reload the page, but keep all in place assign a submit handler to the form element, call preventDefault() and do all the JS magic you want to do:

  • You can still have a keypress handler on the input element if you want to interact with the entries while they happen. If you look at the code on the page now, all it does is check for the enter button. Hitting the enter button in a form with a submit button or a button element submits the form – this whole code never has to be written, simply by understanding how forms work.
  • You can change the value of a submit button when the submit handler kicks in (or the innerHTML of the button) and make it inactive. This way you can show a loading message and you prevent duplicate form submissions

What’s wrong with autofocus?

Visually and functionally on a browser that was lucky enough to not encounter a JavaScript error until now, the autofocus solution does look like it does the job. However, what it does is shift the focus of the document to the input field once the page has loaded. A screenreader user thusly would never ever learn what the site is about as you skip the header and all the information. As the input element also lacks a label, there isn’t even any information as to what the user is supposed to enter here. You sent that user into a corner without any means of knowing what’s going on. Furthermore, keyboard users are primed and ready to start navigating around the page as soon as it loads. By hijacking the keyboard navigation and automatically sending it to your field you confuse people. Imagine pressing the TV listings button on a TV and instead it just sends you to the poodle grooming channel every time you do it.

The web is obese enough!

So here’s my plea in this: let’s break that pattern of working on the web. Our products don’t get better when we use fancier code. They get better when they are easier to use for everybody. The fascinating bit here is that by understanding how HTML works and what it does in browsers, we can avoid writing a lot of code that looks great but breaks very easily.

There is no shortage of articles lamenting how the web is too slow, too complex and too big on the wire compared to native apps. We can blame tools for that or we could do something about it. And maybe not looking for a readymade solution or the first result of Stackoverflow is the right way to do that.

Trust me, writing code for the web is much more rewarding when it is your code and you learned something while you implemented it.

Let’s stop adding more when doing the right thing is enough.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

7 things about working in I.T. you don’t learn in school

Disclaimer: this is the script, well, the notes, for a presentation I am giving at Spotify in Sweden this weekend as part of the Studenttechfest. I was asked to give an inspirational keynote telling students what working in IT is like. The slides and recording will be available afterwards.

1) The “how” lands you a job, the “why” lands you a career

In I.T. there is what I call a “fetish of the how”. We are obsessed with finding and showing quick and intelligent solutions for problems that abstract away the original issues in order to make us more effective and use less time to achieve our goals. I remember a Dilbert cartoon in around 1996 that hit the nail on the head. Dilbert explained when asked why he uses computers all the time that they make him much more effective and save time. When asked what he does with the time he said he does more computer stuff and his friend went “wow, so you can save even more time”.

stop listening to ducks

This culture of giving you a “how to do things” instead of “why they work” starts perpetuating a false belief that what we do is easy and can be learned quickly by doing an online course or looking things up in Google. Many of the threads on sites like Stackoverflow are just repeated answers stating that “you just do this and everything works”. Sites like W3Schools are very successful as they show how to do something and give you the promise that you can achieve anything by just copying and pasting an answer. Why bother with understanding what you do when you could already deliver?

Organic Unicorn Farts

The issue is that a lot of quick solutions start breaking really soon and then you are stuck as you don’t know what you did. You used magic, and not even yours and you aren’t even a wizard. There is nothing wrong with using free resources and abstractions and be more effective. In order to be professional, however, you also need to understand how they work and be able to create working solutions without them. This is when you start becoming someone who can be hired and offered a career. Otherwise you can get a job as a deliverer or maintainer but no company in their right mind would invest in you as your attitude is that of those who try to dazzle and really don’t not know what they are doing.

2) It is a ride, hop on and take in the scenery

I.T. is probably, with the exception of acting and journalism, the most versatile job market out there. Things are constantly in flux and there is not much boredom if you are excited about building things from zeros and ones.

Never look back

You will encounter a lot of products, frameworks, software packages and practices along the way. Take them in and deliver with them. Stay agnostic though as things are continuously changing. In every job there is something new to be learned and whilst your task is to deliver it you can also learn from the mistakes made and the results of shortcuts taken. Try everything and you will find patterns over time that help you make better decisions later on in your career.

3) Be a collector and an archivist

Working in a constantly changing environment also means a lot of drama, a lot of problems and egos clashing. Be aware of that and prepare for it. Even when you disagree with people strongly – if they are your manager and tell you something needs to be done the best way is to ask why and you might learn about outside pressures you weren’t aware of before.

Don't burn bridges

The I.T. world seems large, but it is actually pretty small. When leaving a job, don’t leave in anger. Don’t burn bridges as you will come across people later on you are very much sick of right now. You might even realise that in another environment these people will be brilliant to work with. You make a career by forging personal relationships. Collect great people to work with and keep up to date with what they are doing. Most great jobs come from word of mouth. Not via LinkedIn.

4) Your degree opens doors, your passion opportunities

Once you are done with university, you have your degree and many jobs require a degree as a right of passage. This means you can and will easily get a job. However, lots of other people also have degrees and as someone who hires I am looking for other, additional features. You are about to embark on a great journey, one of privilege, really. No other market is booming like I.T. and the things companies do for us make other people gape in astonishment.

Pawing puppy

Therefore, as a prospective employee, I am looking for passion in you. One of the main complaints by hiring managers is that people come into the job interview not knowing anything about the company they apply for. This is a bad first impression, as if you don’t care about the company why should the company care about you? Talk about your passions, give me an indicator that you want to get better and you are ready to learn more. Then I am ready to take you on and do a lot more for you than just pay you.

5) Nothing stops you from building a reputation now

There is no better way to get hired than to be known as someone who cares about sharing, giving feedback and showing technical and social aptitude. The good news is that this is amazingly simple these days.

touch my hair for a dollar

The main issue is that becoming known and being visible can be easily seen as showing off and in many cases actually is. In the US, this is part of a career; you have to sell yourself. As a European this can be daunting and feel wrong, but sometimes we need to jump over our shadow.

A great way to be visible is to go out there and speak about things you do. This is scary, but it is also a great way to get into the business. The simplest way to do that is to attend meetups and unconferences.
However, you don’t have to put yourself out there immediately, participation and visibility can be achieved much easier.

GitHub managed to make the impossible possible: it is a social network for engineers, people not generally known for being too social. On GitHub you can not only get lots and lots of great, free software but you can also become part of it. You can contribute code, you can file issues and help with testing, you can comment and help work around people’s differences. All of this brings you brownie points when it comes to applying for a job and looks much better on a CV than hypothetical achievements.

It is important to remember that your bad behaviour online is also noted by prospective employers. It might be fun to start a flame war and to troll people, but it can also mean the end of your career before it started. Playing nice is a good idea.

6) Being mobile and flexible gets you places

One ironic thing about I.T. is that whilst we are all connected world-wide, a lot of times traveling to other places to work with people face to face is necessary. Therefore it is important to be flexible about this. Many of my career jumps happened because I was OK to work from a different location for a short while. This also gave me a lot of interesting experiences I took with me.

Taking on an opportunity to work with a remote team is a great move in your career. The problem of making distributed teams work efficiently is still a big one for a lot of companies. If you already manage to have a fruitful collaboration with people from other timezones and cultural backgrounds you become a very interesting asset to companies out there.

7) Find a place to grow, not just a place to get paid

Lastly, I want to point out that I don’t see any way that you could not end up with a good job right now. The question you have to ask yourself is what you want to do. My advice is to find a place you feel great, you can be part of a team you respect and you see opportunities to learn new things. That is much more important than being paid a lot. Burnout is a big problem, and you should consider planning for a longer career rather than being a rockstar for a season and then feel like you already need a break at 22.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Five things you can do to make HTML5 perform better

During the last few weeks we were busy helping developers to convert their HTML5 apps from platforms like WebOS and ChromeOS to FirefoxOS and the target hardware this operation system is right now aiming for. As these are slow mobiles, we found that quite some tweaking had to be done. The reason was in most cases libraries using outdated ways to animate and position things on the screen. These old ways of working are needed to support legacy browsers and in a lot of cases are not needed as these legacy browsers will never see the apps in the first place.

Speeding Through The Klongs

Aside: I will cover a lot of this in my keynote at the jQuery Europe conference called “Helping or hurting?”.

Tip 1: Use CSS animations/transitions

Instead of using your library’s animate() which – for now – uses many badly performing technologies (setTimeout, top/left positioning) use CSS animations. In many cases actually Transitions are enough. The reason is that browsers optimise them for you and hardware accelerate them. Another benefit is that the animation is defined in the CSS with the rest of the look and feel and in an agreed standard syntax. CSS animations give you massively granular control over the effect using keyframes and you can even listen to events that happen during the animation. You can easily trigger the animations in CSS with hover, focus or target selectors or by dynamically adding and removing classes to a parent element. If you want to create animations on the fly or modify them in JavaScript, James Long has written a simple library for that called CSS-animations.js

Tip 2: Use requestAnimationFrame() instead of setInterval()

This has been explained many times – a setInterval() call runs code at an assumed frames per second speed that may or may not be possible. It tells the browser to render results even whilst the browser is currently not drawing as the video hardware is not in the next display cycle. On the other hand, requestAnimationFrame() will wait till the browser is ready and only send your changes when they will result in a visual display. Another great side-effect for using rAF is that animations don’t happen when the tab is inactive – that way your app is not responsible for hammering the CPU/GPU and sucking battery whilst it doesn’t do anything for the end user.

Tip 3: Use CSS transforms instead of position: absolute and top/left

Again the reason is hardware acceleration. CSS transforms using translate(x, y) run on the GPU whereas positioning absolutely and using top and left hammer the main processor. This is worsened by not rounding your pixel positioning. Using transforms also means that you have a much bigger arsenal at your proposal. Rotation and 3D transformations just mean adding to the transform string. With top/left you need to calculate them yourself and mess around with depth of field. Paul Irish has an in-depth analysis of the benefits of translate() from a performance point of view. In general, however, you have the same benefits you get from using CSS animations: you use the right tool for the job and leave the optimisation to the browser. You also use an easily extensible way of positioning elements – something that needs a lot of extra code if you simulate translation with top and left positioning. Another benefit is that the technique is the same in Canvas.

Tip 4: Make events immediate

As old-school, accessibility aware web developers we love click events as they also come with the added benefit of supporting keyboard input. On mobile devices these are too slow though and you should use touchstart and touchend instead. The reason is that these don’t have a delay that makes the interaction with the app appear sluggish. If you test for touch support first, you don’t sacrifice accessibility either. The Financial Times use a library called fastclick for that purpose, which is available for you to use.

Tip 5: Keep it simple and re-use as much as you can

One big performance issue we found in HTML5 apps was that moving lots of DOM elements around makes everything sluggish – especially when they feature lots of gradients and drop shadows. Simplyfying your look and feel and moving a proxy element around when you drag and drop helps a lot.

When you have for example a long list of elements (let’s say Tweets) don’t move them all but only keep the ones visible in the current screen and a few before and after live and hide or remove the others. Keeping the data in a JavaScript object instead of reading/writing to the DOM showed massive improvements. Think of the display as a presentation of your data rather than the data itself. That doesn’t mean you can not use straight HTML as the source. Just read it once and then scroll 10 elements changing the content of the first and last accordingly to your position in the results list instead of moving 100 elements that aren’t visible. The same trick applies in games to sprites – if they aren’t in the current screen there is no need to poll them. Instead re-use elements that scroll off screen as new ones coming in.

More reading:

(Includes videos and all)

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Ten Things Developers should know about the Mozilla Developer Network (MDN)

The Mozilla Developer Network (MDN) is one of the most popular resources for developers on the Web. Designed by developers for developers, MDN helps support Mozilla’s mission to promote openness and innovation on the Web.

As an open, community-driven wiki, MDN provides Web developers, designers, application developers, and extension and theme writers with access to the best documentation, tutorials and developer tools available. Anyone can add and edit content to make it even better. It’s used by developers building resources for a better Web, regardless of brand, browser or platform.

To give you a quick overview of what developers can get out of MDN we’ve put together this Top 10 list of things you should know about MDN and some tips on how to get involved.

Enjoy!

  1. One of the most popular resources for developers on the Web with over 4.5 million page views and 2 million visitors per month.

  2. One of the richest resources on the Web for documentation:

    49,748 documents and climbing
    9,185 contributors have made 272,134 edits to date

  3. An active developer community in the MDN IRC channels including: #mdn-dev, #devmo and #mdn.

  4. The only developer site to be localized in 15 languages. MDN offers translations in 15 languages for HTML docs, 13 for CSS, and 11 for JavaScript. All of these translations are created by a global community of volunteer localizers, who prioritize translation of topics based on local needs and interests. See where localization help is needed.

  5. The best destination for JavaScript reference documentation anywhere.

    “MDN is hands down the best resource for finding quality JavaScript documentation. It’s well organized allowing developers to quickly find the information they need without poring through multiple specs,” – jQuery core committers

  6. A great resource for developers looking for a wide variety of freshly updated content. MDN is maintained by the community of developers and technical writers and hosts literally thousands of documents on a wide variety of subjects such as: HTML5, JavaScript, CSS, Node.JS to name just a few.

    For Mobile Web developers, MDN provides documentation such as: How to build HTML5 mobile apps or build a mobile add-on or learn about location aware apps.

  7. Anyone can edit or add documents to the wiki, you just need to create an account and start. Don’t worry about asking for permission; don’t worry about making mistakes. On the other hand, if you are going to be working on the site it does help to get to know the MDN community – we’re friendly and here to help!
  8. Rich with community-submitted demos; over 500 and climbing. MDN introduced “Demo Studio” in 2011 – for web developers to share and show off their code.

  9. Each month, the Dev Derby provides a different challenge to developers – from offline apps to “no JavaScript” (the most popular Derby topic in 2012, with 71 entries). A panel of distinguished judges choose the prize-winning entries.

  10. A new HTML wiki was launched in August of 2012 – meaning developers don’t have to learn a new markup language to edit and write docs. The platform is open-source and based on Django, so developers can add new features and functionality to the wiki from Github. Also a new HTML5 WordPress plugin was launched that lets developers hotlink words on their blog to MDN.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Being a better web citizen: complain where things get fixed

We like to complain. It feels good, it feels like we are doing something that will make things better. The problem is though, if we don’t complain where things can be changed we are not making things better. In a lot of cases we make them worse. In almost all cases where we don’t complain at the source we actually make people feel worse and share our frustration rather than initiate change.

The right to complain

I remember when that volcano in Iceland erupted and messed with all the flights in Europe. I was scheduled to come back from San Francisco and got sent to 3 different airports in the US. I was in Chicago in a totally rammed airport and queueing up to get a new ticket with about fifty people before me and two hundred or more behind me. A group of three people in front of me had their tickets already and yet were in the queue for the ticket counter. I asked them what they are doing here as they do have their tickets, wondering if I was in the right queue. I was. Their answer was “yeah, we want to complain about the delays!”. I handed them my phone to write an email to the airline and explained that complaining to the person behind the ticket counter about a thing that is incredibly obvious doesn’t help them or the already freaking out person who is faced with a line of 200+ people they probably can not help easily. I was unlucky. Logic doesn’t count when there is exercising the right to complain to be done. It is just another sense of entitlement people seem to need to excercise or else they don’t feel like they are being appreciated. Or something.

Complain where work is being done

In any case, on the web and when it comes to web development or web technology issues it is ridiculously easy to complain where a complaint makes sense and will result in a change that makes things better for everybody. If there is a GitHub repository and you have a problem with the code, file an issue. If you have something that bothers you with browsers, file a bug.

This is the only place where you should bring your worries. In a lot of cases you will find that other people had the same gripes and they have been fixed or need a certain trick to work. Anything else you do is add to the noise of the internet without causing any change. Actually, you might expect others to do work for you.

This is one thing I changed in my behaviour on Twitter and elsewhere lately – and so far it did me only good. We do not need conversations about seemingly broken issues of products without the people who create and maintain the product being involved. If they are hard to reach, then this is what should be fixed. Complaining about details to people who might be able to tell the people who should fix the issues doesn’t mean they will get them – it just means you frustrate even more people.

So next time you find yourself feeling the need to exercise the right to complain – or just feel like venting – spend some time finding the right person to complain to. A lot of times you find your anger is less than you initially think it is and many a time you will find that you did something wrong in the first place.

Got a comment? Add to the thread on Google+


View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)