Back to School – Information Architecture

What is Information Architecture?

Information architecture is the practice of deciding how to arrange the parts of something to be understandable. It is in the websites we use, the apps and software we download, the printed materials we encounter, and even the physical places we spend time in.

A good Information Architecture helps people to understand their surroundings and find what they’re looking for – in the real world as well as online. Practicing information architecture involves facilitating the people and organizations we work with to consider their structures and language thoughtfully.

Information Architecture is a key component of your website

Information architecture (IA) focuses on organizing, structuring, and labeling content in an effective and sustainable way. The goal of IA is to help users find information and complete tasks. To do this, we users need to understand how the pieces fit together to create the larger picture, how items relate to each other within the system.

As many students (and teachers) begin a new term this month, we thought it would be helpful to review some of these fundamental tenants. It is always a good idea to focus on the basics and make certain we have a solid foundation.

The article Information Architecture Basics has more information on the following main components of IA:

  • Organization Schemes and Structures: How you categorize and structure information
  • Labeling Systems: How you represent information
  • Navigation Systems: How users browse or move through information
  • Search Systems: How users look for information

Why is information architecture important?

Site navigation is a very important part of any website interface, as it influences the usability of your site. Information architecture is the structural design of your information, and includes the art of organizing and labeling items to insure usability and findability.

Here is the article explains what is website navigation and information architecture and how do they work together.

What is the difference between UX and Information Architecture?

IA (Information Architecture) professionals focus on how things are organized. It’s a specialized job, usually for websites. Very often this is for an agency or a large corporation where people are highly specialized. UX (User Experience) is all-encompassing for the experience of someone interacting with your company.

This article focuses on the difference between information architecture and UX Design.

Additional Resources

This is another week in Back to school Basics. This week’s focus is information architecture basics, why IA is important and what is difference between IA and UX users?

We hope you find these resources and overviews useful. We always look forward to your comments and feedback (whether you are a member or not).

We encourage members (and non-members) check out our social media channels. If you aspire to be a web professional and don’t know where to start, we offer a number of beginning classes to our members via our School Of Web learning management system. As a member, your first class is free.



The post Back to School – Information Architecture appeared first on Web Professionals.

View full post on Web Professional Minute

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

Back to School – Semantic Markup Review

What is Semantic Markup mean?

Semantics is the study of language meaning – the words used to communicate. Semantic markup should be used in web pages we create and modify.

In our technology world we use semantic language. Semantic HTML is the use of HTML markup to reinforce the meaning of the information in webpages and web applications rather than merely to define its presentation or look. Semantic HTML is processed by traditional web browsers as well as by many other user agents.

For HTML it is the tags we use to mark a document up. Markup is how a web document is created, or the way you write a document using the language available to you. For most web documents this is still HTML, so it is how you write the content you want to display using HTML.

Words and semantic markup matter

This older article gives addresses these questions.

  • What does semantic markup mean?
  • That’s enough theory! What does it mean?
  • The danger of CSS
  • So why does semantic markup matter then?
  • Microformats – Semantic Markup on Steroids
  • I’m sold – what next?
  • I’m not sold – it is all a load of rubbish!

Why You Should Care About Semantics?

The benefit of writing semantic HTML stems from what should be the driving goal of any web page— the desire to communicate. By adding semantic tags to your document, you provide additional information about that document, which aids in communication. Specifically, semantic tags make it clear to the browser what the meaning of a page and its content is.

That clarity is also communicated with search engines, ensuring that the right pages are delivered for the right queries.

The article Why to use Semantic HTML? covers the following aspects of using semantic markup.

  • What is Semantic HTML
  • Why You Should Care About Semantics
  • Use Semantic Tags Correctly
  • Which HTML Tags Are Semantic?
  • Semantic HTML Tags

How to Use Semantic Markup to Improve Your Search Results?

Semantic markup is a fancy way of saying you can use HTML tags to tell search engines exactly what a specific piece of content is. Without semantic markup, search engines rely on context to determine what your content relates to. That takes a little longer because search engines don’t read like humans do. With semantic markup, search engines immediately know what your content is and can index it faster and more accurately.

To get more information read this article How to Use Semantic Markup to Improve Your Search Results.

What is Microdata?

Microdata is part of the WHATWG HTML Standard and is used to nest metadata within existing content on web pages. Search engines, web crawlers, and browsers can extract and process microdata from a web page and use it to provide a richer browsing experience for users. This link has the details about Microdata and how one can use it for search engines.

If you wish to learn more…


Many schools are starting in the next week or two. We decided to focus on a number of basic concepts in the coming month to help teachers reinforce industry best practices as they begin a new school year.  We focused on Semantic Markup in HTML this week as many simply don’t understant the necessity of using a <nav> tag instead of a <div>.

We hope you find these resources and overview useful. We always look forward to your comments and feedback (whether you are a member or not).

We encourage members (and non-members) check out our social media channels. If you aspire to be a web professional and don’t know where to start, we offer a number of beginning classes to our members via our School Of Web learning management system. As a member, your first class is free.



The post Back to School – Semantic Markup Review appeared first on Web Professionals.

View full post on Web Professional Minute

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

Developer Relations revelations: social media can be pretty anti-social

This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.

Loose tweets sink fleets

So, today, let’s talk about social media.

Social media is one of the most powerful things for a DevRel person. It is also a tricky one to navigate. As a DevRel person you skate on thin ice. You need to remain a person and a face people can remember and feel comfortable contacting. But you also represent a company.

People on social media are much more likely to follow and listen to a personal voice than a company account. In my personal experience, you also have more longevity. A corporate account promoting a product can cause a massive spike in traffic. A personal account causes traffic for a few days. People are reading your updates at different paces.

So, as a DevRel person, you have the challenge of having to be yourself and to represent a company. And that comes with a lot of baggage.

You need to be careful not to mix your personal views (or ones that people think you have) with company updates. And there is no such thing as “sins of the past”. What you posted and how you acted can be dug up years later and used against you. Many celebrities right now have the same experience. DevRel people – for better or worse – are minor celebrities (in most cases we don’t want to but it happens). So, the glib post you put out in a party mood five years ago can and will be used against you.

I am trying to mitigate this risk by having a detailed Twitter manifesto where I explain my usage of the channel in detail. I am pretty sure that this will not mean much when push comes to shove but I had good feedback on it.

My rule of thumb is that social media is an entry point. An entry point to get people to communicate with you one on one. An entry point to get people to use official channels to voice their ideas and concerns. I avoid having long conversations and communication threads on social media. The reason is that they always end up messy, because social media isn’t social any longer – it is a business.

Social media is a numbers game

People game social media – big time. By now it feels spammy and annoying. “Growth hackers” and “Social Media Experts” spoil it for everyone. It feels like back when Search Engine Optimisation (SEO) messed with the web. Our carefully crafted and educational posts drowned in a mess of “7 things you should know about…” and “45 essential jQuery plugins” bullshit articles, crafted to optimise eyeballs and clicks. Social media is a similar race at the moment. You can buy followers and likes and many a bot upvotes others. Adding your voice to a thread – no matter how wrong – gives you eyeballs. Almost every longer conversation sooner or later ends up with baiting and leading people to say something controversial that can be taken out of context. You somehow need to stand out of this quagmire. I got to be very careful over the years, and actively avoid getting roped into discussions.

Separation of products and people is a must

Social media is full of terrible people and bots you don’t want to get associated with – even by accident. Who you retweet and share also reflects on you. So be aware what and who you endorse. Make it perfectly clear that an endorsement of a product doesn’t mean you necessarily agree with the creators.

Context on social media is a joke

Whatever you put on social media will be taken out of context. Make sure your updates are clear and precise. Don’t allow people to quote you to support something you don’t want to be associated with. This is especially dangerous when you talk about your competition. Negative remarks about them are completely out as this is a headline in the making you don’t want to defend yourself against. Positive remarks about your competition can easily turn into a messy conversation with your own company (more on that in the final part of this series). But here’s the issue – to be successful on social media as a DevRel person, you have to talk about other products than your own. And that includes your competition.

You are always one remark away from being a shill

OK, we all know that you are paid to represent your company, its products and get people to try them out. You are also there to get feedback and bring that back to the company. All this is dependent on your reputation and the trust people have in you as an expert in the field. That’s why it is imperative that you have your ear on the ground and talk about exciting things on social media. You need to be a go-to expert for people to find out about exciting new things and to get feedback on their own ideas and products. The perfect scenario is when your products are making a lot of sense to you. Then you can promote them by showing what you build with them. But, the more successful you become, the more your company will also ask you to promote their other products. And this is where it gets annoying to be on social media. When you promote a product people know you don’t use you will get a lot of backlash. Often it makes most sense to point to other social media accounts to do that promotion. Or to coach the other department of the company to create some post or demo that you can point to without looking like a sales rep.

What your company does is all your fault

On the flipside, whatever your company does will always be your fault. It doesn’t matter if you are one of thousands of people in the company. It doesn’t matter that you are far removed from the product or the happening that annoyed people. You are publicly visible, available and you have a history of being responsive. So there you are.

This gets tougher, the bigger your company is, and the more the press loves to report about it. Talking to colleagues at Google, Samsung and other big players, we all have the same experiences. It is pretty unfair to have your life decisions questioned every time something controversial happens to your employer. It is even worse when people ask you about a quick statement. Often because what your company allegedly did is at odds with what you are about. The very important solution to covering your arse here is to have a good relationship with the PR department of your company. Don’t fall for the bait, don’t make public statements. By all means, though, report in the company what you heard – that’s where changes can happen.

You’re seen as the magic way-in

On a less stressful topic, people will always assume that you wield a magic wand to get things done in your company. That bug report a random department of your company hasn’t answered in months? Sure you can simply talk to them and it will get fixed immediately? That just announced new product or service? Surely you have a free one lying around? And you can get one of your thousands of online friends free, unlimited access. You also have the magic powers to get anyone hired without any of the normal procedures, right?

All this is flattering, but also dangerous. Communication channels in your company are there for a reason. You can sometimes accelerate them, but it is important to do a cursory introduction and then pull out. You don’t want to constantly play a game of telephone being a mediator as that takes up far too much of your time.

Alas, it makes a lot of sense to be active on social media

Social media is a great way to get information out, and to keep up to date with what other people are doing. As a DevRel person, it is much more agile and simple than cold-call emailing people. The main task though is find a good balance of staying true to yourself but not fall into any of the dozens of traps social media has these days. You are under a massive spotlight, better watch your moves and count to ten before you answer and publish something that can never be undone.

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) – hinting at a better web

Webhint logo

Humans are a weird bunch. One of our great traits is that when someone tells us that a certain thing is a certain way, we question it. We like debating and we revel in it. The more technical you are, the more you enjoy this. As someone once put it:

Arguing with an engineer is like wrestling with a pig in shit. You realise far too late that it enjoys it.

Now, the web as we have it these days isn’t in a good place.

  • It is slow, full of unwanted content
  • It allows others to track our users without our knowledge
  • It is full of security holes and much less maintained than it should be to prevent them becoming an attack vector
  • It lacks support for physical and digital availability for all.
  • Developers get very simple things wrong and often a mistake is copied and pasted or installed over and over

That means that browsers, which by definition can not break the web, need to be lenient with developer mistakes. All browsers fix a lot of problems automatically and allow for spelling mistakes like “utf8” instead of “UTF-8”. That also makes them bigger, slower and harder to maintain. Which makes us complain about browsers being just that.

It can’t be a problem of lacking resources

Considering how much free, high-quality information we have available this is weird. We have web documentation maintained by all the big players. We have up-to-date information on what browsers can do. We drown in conferences, meetups and we don’t even need to attend them. Often talk videos pop up on YouTube within minutes after the presenter left the stage.

We also have excellent tooling. Browsers have developer tools built in. Editors are free, some even open source and we can configure them to our needs using the languages we use them to write. We have automated testing and auditing tools telling us what to optimise before we release our products.

Maybe it all is too much to take in

The problem seems to be overload. Both of options and especially of opinions. We can’t assume that every web developer out there can go to conferences, follow blog posts and watch videos. We can’t assume that people can deal with the speed of news where a “modern, tiny solution” can turn into a “considered harmful” within a day. We also can’t assume that what is a best practice for a huge web product applies to all smaller ones. Far too often we’ve seen “best practices” come and go and what was a “quick, opinionated way to achieve more by writing less” turned into a stumbling block of the current web. Even more worrying, when a huge successful corporation states that something works for them developers are asked to use these settings and ideas. Even when they don’t apply to their products at all.

There is no one-size-fits-all best practice

The web is incredibly diverse and the same rules don’t apply to everything. We are very quick to point the finger at a glaring problem of a web product but we don’t ask why it happened. Often it is not the fault of the developers, or lack of knowledge. It is a design decision that may even have a sensible reason.

We faced the same issues at my work. Working in a large corporation means many chefs spoiling the broth. It also means that different projects need different approaches. I am happy to give Internet Explorer users a plain HTML page with a bit of CSS and enhance for more capable environments. But not everybody has that freedom – for them a high-quality experience on that browser is the main goal. Everything else isn’t part of the product time buffer and needs to be added on the sly. Different needs for different projects.

Damage control

That said, we didn’t want to allow low-quality products to get out of the door. Often us in the inner circle of the “modern web” preach about best practices. Then some marketing web site by your company makes you look silly because it violates them. We needed a way to evaluate the quality of a project and get a report out of it. We also needed explanations why some of the problems we have with the product are real issues. And we needed documentation explaining how to fix these issues.

This is when we created a product that does all that. It is a scanner that loads a URL and tests all kind of things it returns. It uses third party tools to test for security and accessibility issues and is available open source on GitHub. As we don’t want this to be just a thing of my company, we donated the code to the JS foundation.

At first, we called the product Sonar. That was a copyright issue. So we renamed it to Sonarwhal. It had some success, and then more naming clashing issues cropped up. Furthermore, people didn’t seem to get it.

Today, we released a new, rebranded version of the tool. It is now called Webhint and you can find it on GitHub, use it at or use it as a node module using npm, yarn or whatever other package installer you want to use.

The simplest use case is this:

  • Go to Enter the URL you want to test
  • Wait a bit till all the hints came back
  • Get a report explaining all the things that are sub-optimal to dangerous. You don’t only get the error messages, but detailed explanation what these mean and how to fix the issues.

By default webhint tests for these features of great web products: Performance, Accessibility, Browser Interoperability, Security, Sensible configuration of build tools and PWA Readiness.

Make up your own tests checking what matters to your product

Whilst this is great, it doesn’t solve all the issues we listed earlier. It is a great testing tool, but it has its own opinions and you can’t change them.

  • What if your tool doesn’t need to be PWA ready?
  • What if performance is less of an issue as you run on an intranet behind a firewall?
  • What if you can’t access as you are working in a closed network?
  • What if you don’t use a browser at all but you also want to test a lot of documents for these quality features?

This is where the node version of webhint comes in. You can get it and install it with npm (and others, of course). The package name is hint .

Animation of hint on the command line

That way you can not only scan a URL from the command line, but you can also configure it to your needs. You can define your own hints to test against and turn the out-of-the-box ones on and off. You can turn off the ones reliant on third party scanners. You can even have different configurations for each project.

With the release today of webhint, we took what was Sonarwhal and made it faster, smaller and easier to use. The command line version now has a default setting and adding and removing hints is a lot easier. The startup time and the size of webhint is much smaller and things should be much smoother.

So go and read up on the official release of Webhint, dive into the documentation or just do some trial scans. You’ll be surprised how many things you find that can have a huge problematic impact but are relatively easy to fix.

I hope that a tool like webhint, without fixed opinions and customisable to many different needs whilst still creating readable and understandable reports can help us make a better web. Watch this space, there is a lot more to come.

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)

August Update – ‘Skills new hires should have’

What work skills can make you more marketable to employers in 2018?

Change is always constant. So naturally, the job skills that employers look for in new hires change from year to year. It’s one of the best ways for companies to stay competitive and ahead of the never-ending curve. According to Julie Friedman Steele, board chair and CEO at World Future Society “The workplace moves rapidly and employers need workers who stay current.” That means you need to consistently improve your skills and develop new ones.

Many small notes about various business processes

Here are 7 work skills most employers look for –

  • Problem solving
  • Data analytics
  • Social media literacy
  • Creativity
  • Resiliency
  • Good business sense
  • Willingness to learn

This list comes from a good article covering 7 work skills which make you more marketable to employers in 2018. Note that most of these relate to non-technical skills. Those are assumed these days.

What is the difference between Hard Skills and Soft skills?

Hard skills are specific, teachable abilities that can be defined and measured, such as typing, writing, math, reading and the ability to use software programs. By contrast, soft skills are less tangible and harder to quantify, such as etiquette, getting along with others, listening and engaging in small talk.

Here is a good article explaining more about the difference between hard skills and soft skills.

More information

While soft skills aren’t often explicitly tested in interviews, they can be a huge part of what makes or breaks a hiring decision as they are playing an important role in making employees successful in any work environment. Whether you’re looking for a new role or hoping to advance within a company, focus on these soft skills that top companies look for in potential and current employees.

This week we focused on the work skills everyone should have. Hard, technical skills are important but ‘soft skills’ often play a critical role in the hiring process.

We hope you find these resources and overviews useful. We always look forward to your comments and feedback (whether you are a member or not).

We encourage members (and non-members) check out our social media channels. If you aspire to be a web professional and don’t know where to start, we offer a number of introductory technical classes to our members via our School Of Web. As a member, your first class is free.

The post August Update – ‘Skills new hires should have’ appeared first on Web Professionals.

View full post on Web Professional Minute

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

JavaScript: more puppy love, less fatigue

JavaScript is everywhere and it is the hottest thing to have on your CV. For now. Python is gaining and Deep Learning is to blame, but I digress. With JavaScript’s hype we also talk a lot about JavaScript fatigue. People feel overwhelmed by the sheer volume of things you can do with it. Or?—?even more to the point?—?the amount of work you have to put into setting up your JavaScript environment. And the tools you “need to use to be professional”.

I’m not suffering from JavaScript fatigue. The reason is that I didn’t come in that late. I was lucky enough to see JavaScript grow to what it is now. To me, JavaScript is still that cool rebel of the programming languages world. I remember being laughed at by Java and Perl developers for wasting my time on that toy language that didn’t even come with a package manager. I’m not a purist that says all these things are stupid or unnecessary. Far from it. It is amazing how far we have come in our tooling. But- maybe?—?we could achieve more with new developers starting out if we started them with Vanilla JavaScript rather than throwing the kitchen sink of tooling at them.

What people hate about JavaScript is the thing I love about it. It is a mess. It is not ready yet and there is still so much it can do.

I feel a kind of neoteny attachment to JavaScript.

neotenyni???t(?)ni/noun – the retention of juvenile features in the adult animal

In other words, instead of showing people the current form of JavaScript as a matured, highly domesticated and fierce animal, we should get people to know it as a puppy. That’s how I got to know it. Instead of wondering what packages to install and how to set up my server to run it, I wanted to grab it, cuddle it, play with it and?—?above all?—?protect it and its surroundings from harm.

Mastiff puppy
Look at that guy! Lots of wrinkles to even out, but eager to play. That’s JavaScript

My relationship with JavaScript began very early. So early, that it didn’t do much and we couldn’t do much wrong. That didn’t stop us though from doing wild things. As a web developer, JavaScript itself wasn’t quite as interesting as what it can do in browsers. The years of document.write, framesets and popup windows came first. I had quite some “fun” trying to make things work across browsers. DHTML was the next hype where it was most important to create cool effects?—?no matter the cost. Considering standard compliance or what technical debt we accumulate was less exciting.

We all knew that JavaScript wasn’t a “real programming language” and that was what made it interesting. You didn’t need to use an IDE, you didn’t need to compile your code or set up an environment for it. You took any editor, wrote your code and the browser did the rest.
Until it didn’t any longer. Around the same time of the bursting of the first dotcom bubble IE stopped reigning supreme. Other browsers started to matter and clients complained about things breaking. JavaScript got less fashionable again. Instead, everybody started betting on Flash. It promised to eradicate cross-browser differences and give you full control.

In the JavaScript world, we sobered up a bit. We realised how brittle the things we built were and started to advocate for a more sensible use of JS. We also had a good reason, as the DOM finally got standardised and things were much more predictable than in the first browser wars.
In 2004, I wrote the self-training course on Unobtrusive JavaScript explaining how you can use JavaScript without relying on it. As an enhancement, it works wonders. As something to rely on, lots of things work against you.

When DOM-1 was available, I followed up with From DHTML to DOM Scripting with detailed advice to not make the same mistakes again.

Things got more solidified with the WASP DOM Scripting Task Force that started in a pub after a conference in London. The most visible influence there was probably Jeremy Keith’s DOM Scripting book.

JavaScript itself didn’t move much though. The language was still what Brendan Eich and others created in a 10 day sprint to have a client-side language. And when things get that frantic, shortcuts happen.

Over the years, we tried to make the language itself better and more predictable. We couldn’t change it as that would break backwards compatibility. So we found clever ways to work around issues.

One of the big consumers of these were JavaScript and AJAX frameworks and libraries. YUI, Dojo, jQuery and others were a great test-bed to make JavaScript work for developers but also to fix some of the issues of the language itself.
The immediately-invoked function expression was a clever way to work around the global variables issue. Douglas Crockford’s Module pattern ensured encapsulation (until eval() also got a scope parameter). I’ve found the Module Pattern annoying to write, so I came up with the “Revealing Module Pattern” later on.

Many other patterns and best practices followed. Libraries like mootools and prototype made JavaScript a “proper” object oriented language. At the cost of overriding in-built objects which came back to haunt us now. Other attempts at “fixing” JavaScript were meta languages like Coffeescript and many forgotten ones.

Learning from these fixes and libraries the maintainers and creators of JavaScript, the TC39, release JavaScript much more often these days. And with ES5, we finally have a standard that deals with most issues the first editions had and gives us enough syntactic sugar to be effective.

JavaScript these days has matured a lot and will become even better. It can not, though, when we hide its inner workings away from the next generation of developers.
You don’t need to be a JavaScript language expert to use it. But it may be a good idea to tell the story how we got to where we are rather than asking people to blindly use what’s on offer right now. It is easy to get disappointed, discouraged and overwhelmed by something new when you use it without understanding it. You also don’t dare to say you don’t get it when your peers all stroke their chins pretending to know everything.

Let’s keep introducing JavaScript to people for what it is?—?a language that is pretty messy but highly accessible as there is no barrier to using it. Once they played a bit and see what it can or can not do, we can move on and show that a lot of what we did by hand these days is better served as a pre-built solution. But let’s keep people playing.

If you want to know more, and get a gentle introduction check out my Skillshare class about JavaScript and how to deal with the changes it went through.

In about an hour of videos you learn what JavaScript is these days, how to deal with the hype and – more importantly – what great advances happened to the language and the ecosystem.

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)

Developer Relations revelations: travel is hard work

This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.

So, today, let’s talk about traveling.

Sleeping on a plane

When I worked for the Red Cross with elderly people one thing became pretty obvious to me. People who traveled in their lives were not only more interesting, but also aged much better. They had more energy, showed more excitement about new things and generally felt more alive.

Traveling as a DevRel person isn’t like that. It can easily be the exact opposite.

Coming from a low-end working class family traveling around the world always was a dream for me. Each holiday was cramming the family in a car and driving 14 hours to Italy to go camping. To the same place every year. And yet, I made the best of it. I loved going to highway stops seeing cars and trucks from all kind of countries. I deliberately chose to work on the web as it meant I can connect to people from all over. Getting to know them, finding out our differences and maybe – if I every get really lucky – visit them in real life.

From this point of view my job right now seems a dream come true. It seems that I get paid to travel the world. I have Gold status with one airline affiliate group for three years running. I have Silver and Gold status with a few hotel chains. My travel history is pretty impressive:

My travel statistics, 965369 miles traveled, 1931 hours in the air, 27 countries and 48 destinations

My Android location history
My Android location history See yours here

Here’s the thing though: travel for work is not at all like being on a holiday. It is taxing. It takes a toll on your health, it takes a heavy toll on your relationships and it is very easy to overdo it. You need to be happy with being on your own and being the only person to rely on. You also need to ensure that all your creature comforts get covered. This is often at odds with the budget of conferences or your company’s expense policies.

Faux Jet-Set

There is a strange disconnect in business travel. You are part of the jet set but you almost never have time to enjoy it. On paper it feels great to have travelled to all these cool destinations. In reality all you see is the airport, some means of transport, your hotel room and the event venues. This can be depressing. You constantly have this carrot of world traveler excitement in front of you. To experience it you would need to sacrifice free time. The days before and after an event are crucial for our jobs and it is hard to tack on a few in each direction.

A constant “do I deserve this” feeling

Lonely meals and nondescript rooms are much less fun when you didn’t hang out with people you know. And you don’t want to add yourself to other groups or ask people to dine with you as that would be work. And you need to ensure you have some time off to re-charge. Interestingly enough, the fancier the accommodation is the worse I feel. When I am in a really cool hotel and have no time to use the facilities other than crashing for a few hours I feel weird. I spend other people’s money without reaping the rewards. Trying the hotel out for a holiday later is not as common as they tend to be costly or optimised for business travel.

It is important to be on the road. A two minute face-to-face conversation is often worth weeks of emails, chats or calls. Meeting people where they are can open great opportunities for you and your company. So, here are a few tips that helped me on the way and still make it much easier for me.

Find an airline alliance to collect points and status with.

That means things that don’t sound much but will add a lot to your well-being.

  • You do not have to worry about luggage restrictions.
  • You get priority boarding, which means you can book a cheaper seat and still get on the plane first. You can store your hand luggage above instead of having to keep it at your feet.
  • It is imperative that sooner or later you get lounge access. This turns a layover caused by a missed plane from a nightmare to an opportunity to get some work out of the way. Then you can sleep or relax on the plane.
  • You are also more likely to get upgrades if you have status with an airline. Conferences or your company can book you an economy ticket and yet you travel in comfort.

All hotel loyalty systems are pants

Hotel loyalty systems only give you proper benefits when you book on their web sites or in their apps. With your own, personal credit card. If, like me, you have a corporate card, the most you get is a free bottle of water on check-in (yay?) and late check-outs. There is not much point to be loyal in this case. Something else is much more important when it comes to hotels.

Your hotel matters

Your hotel on a company trip can either be a place to crash at night or your base of operations. I try to make sure I can do the latter. That means the most important part is that it is close to where I need to be. You don’t want to spend a lot of time in transit between hotel and event, carrying a lot of swag and hardware with you. If that means you stay in a cheaper, but closer, hotel, this is a good thing. If it means the conference or your company needs to pay more, so be it. Most trips I do are short which means I will spend most of my time at the event. Having a fancy hotel isn’t useful when you have no time to enjoy it. The most important bits are that the place is clean, has fast connectivity in your room, and is easy to reach.

Stay active – or your health will suffer

If you can, try to find a hotel with a gym – no matter how basic. It is the best thing to fight jetlag and to clear your head. It is also important. When you travel, you sit a lot and you don’t move on a plane. That’s bad for you. You also consume a lot of food and drink on planes and you don’t give your body a challenge to burn it. I found that going to the gym before and after events allowed me to be much more energetic. Look after yourself – nobody else does.

If you’re tired or sick, your work will suffer

Jetlag is a pain and will turn you into a liability. You can not be in a stressful environment when you are not awake and relaxed. You will make mistakes, you will say things you can regret online later and you won’t be able to take in as much as you need. So look after yourself and get sleep when you can. You don’t need to be part of every social activity of an event and should sneak out for a kip whenever you can. Try to get enough time to deal with jetlag and look at what you eat and drink. You can not get sick. And believe me, this is a full-time job. Time differences, over-zealous air conditioning, pressurised aircraft and unknown food all mess with your body. Everyone I know working in DevRel carries a bag of medication. Acid reflux, indigestion, unwanted bowel movements and sore throats and runny noses. All commonplace enough to prepare for them.

Adding to that is that being on the road and constantly having to adapt does things to you. In Pattern Recognition William Gibson describes jetlag as “your soul trying to catch up with you” and that is pretty accurate. Being more emotional without planning to is common on planes. There is a lot of research into Why people cry on planes and I also find myself doing that.

Take care of yourself, please.

Point-to-point annoyances

One thing I am adamant about is that a conference or office makes it as easy as possible for me to get from the airport to where I need to go. I don’t want to deal with pushy unlicensed cabbies. It is also not fun to try to use public transport in a place you don’t know after 30 hours in the air. This may sound whiny and “first world problem”-ish but any minute wasted on the road isn’t doing you any favours. At least demand a good explanation what to do to get there from the people who invited you.

Expenses sound fun, but aren’t

Living on expenses sounds great, right? It is, to a degree, and it would be much harder – and silly – to spend your own money to do your job. But it also means that you need to be diligent about keeping receipts, and note down who you ate with, what and when. You often also have a company card unknown or unsafe to use in a certain place. Then you need to get money out. And you need to explain your company why you didn’t pay by card, suffering twice from the lack of support. It is important to do your expenses on the spot after your trip. Otherwise you end up delayed and get fined. It has become much easier to file expenses digitally now. I remember typing in all receipts, staple them to a piece of paper and mailing them to a different office. Yet, often you wait for weeks for things to get sorted out even now.

Summary: DevRel travel is lost time

When you travel as a DevRel, travel is not a gift any longer. It is a necessary part of your job. Where it is OK to rough it for a holiday, you shouldn’t sell yourself short when it comes to travel for work. It adds to the stress of your job. It takes up a lot of time you could be doing things to diminish the workload you already have. Whilst you can work in a lounge and on a plane I find it not that fruitful. Often I am tired, or euphoric about a certain topic and write a lot of things that sound lucid but are a write-off later on. One exception is going through emails on a plane. Being offline is a great opportunity to take time answering them without distractions. Traveling as a Developer Relations person is a lot of time a matter of good negotiation. Don’t try to be nice by allowing people to put you on a cheap flight and the wrong hotel. You don’t do them any favours as they would get a grumpy, non-effective you rather than the person they invited.

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)

Coding after work Podcast featured me talking about PWAs, Open Source and AI

Back in March, the coding after work podcast interviewed me at the Techdays in Finland.

Today they released the podcast

In about 45 minutes I cover Progressive Web Apps, Microsoft and Open Source and the rise of AI as a technology for us to care about. Hope you enjoy it as much as I did recording it. Thank you to Jimmy and Jessica Engstrom for having me!

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)

Panel discussion at “We are Developers”: The Potentials and Pitfalls of Machine Learning

Back in March I was at We are Developers in Vienna, Austria, gave a two hour workshop on using AI on the web, a talk about code not being the answer to everything and MCed on the main stage on the third day. Another fun thing to do was this panel discussion on the Pitfalls of Machine Learning talking about the ethics and the false definitions of AI we have to battle.

I want to thank all people involved:

Jan Mendling ( @janmendling ), Full Professor at Vienna University of Economics and Business

Charlotte Han ( @sunsiren ) , Deep Learning Marketing Manager at NVIDIA
Tuomas Syrjänen ( @TuomasSyrjanen ), CEO of Futurice
Christian Heilmann, Sr. Program Manager at Microsoft
Rainer Steffl, CIO at Mondi Group

If you want to hear more about this topic and learn how to deal with it, I have a Skillshare course out there :

Chris Heilmann giving his course

“Introduction to Machine Learning: Using Artificial Intelligence” is about an hour of materials to get you familiar with the topic of AI.

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)

Different views on view-source

View source

Over on Jonathan Snook’s blog we have a pretty good debate about a controversial tweet by Tom Dale:

In essence, Jonathan points out that whilst web development has become much more complex, that isn’t a reason to disregard a human readable source:

The increasing complexity of tools doesn’t negate the need for those earlier, simpler tools, though.

In other words, horses for courses. A simple web site doesn’t need complex tools and benefits from view-source. Other, more complex web products are not as interesting to look at as a simple HTML display.

Tom also points out that he doesn’t mean that you shouldn’t be able to peek under the hood of a site, but that as simple view-source isn’t the correct tool.

And you know what? I tend to agree. There is no doubt that view-source was what made the web great. It drove business owners crazy that all their code was readily visible and copy-able in the browser. For developers it was great, though. Almost all learned by looking at what other people do. And by copying and pasting. And this is where it breaks apart.

I want to emphasise this: it used to be great to hit cmd+u and look at a web site in “text mode”. It was even better when the “view-source:” pseudo protocol became a thing. Browsers added colour coding and later on Firefox even highlighted syntax errors in your markup as bold and red.

For a simple web site with everything in one document or a few linked scripts and stylesheets, that was enough.

I don’t think it is any longer though. Even navigating simple source code of a web site is much more fun in developer tools rather than a huge text block. We can right-click on an element these days and go directly to it. We see how the cascade works when looking at its CSS and we even can see attached events and hover states.

Sure, developer tools are harder to learn than looking at a document, but you also learn so much more from them. The beauty of view-source was that it came for free with a browser. This made it a tool of choice for anyone becoming a web developer. There was no need to download and learn an IDE – your development environment was the consumption environment.

Well, that’s exactly what developer tools are these days. They are free, they come with the browser, and they are not impossible to understand. If anything, I like the fact that they give you more insights into what the code does rather than what it is.

The big proponents of view-source tout its usefulness and simplicity. But we can also start thinking about the problems it has:

  • Except for a few purist web sites out there, what you see in your current device isn’t the code of the web site. We shouldn’t ship the same code down the wire for a low-end mobile device than for a retina screen, fast connectivity device. View source is thus giving us a false impression.
  • Code sent to the web is often minimised and bundled. Developer tools give you options to pretty-print those and thus make them much more understandable.
  • Of course it is great that there is no barrier to entry if you want to know how something works. But the forgiving nature of HTML and CSS can also lead to problems. When we released Edge, we found that thousands of web sites defined a text encoding of utf8 instead of utf-8. We needed to fix this in the browser. Clearly people copied and pasted without thinking or validating. And that’s where unexplained code like in a view-source environment fails.

A lot of the fight for view-source stems from a nostalgic view of the internet and how people build for it. Our excitement of learning the web this way is still lingering and we don’t want the next generation to miss out.

But maybe it is time to move on and understand that by sticking to old methods we deprive new developers. When we started, view-source was all we had and resources about what these things mean were scarce. Even worse, they were tinted with corporate needs, rather than following a standard. You learned the Microsoft web from Microsoft, the Netscape web from Netscape and standards when you had the time or listened to those Opera freaks.

I wrote about this back in 2011 in my Lynx would not be impressed – on semantics and HTML post. And now, seven years later, I still think it should be up to the current generation of developers to choose what makes most sense for them. Our nostalgia might actually be hurting the cause.

Snook’s right: we have no right to dismiss or actively block view-source as a means to access code and learn from it. But I don’t think that in today’s development world this is enough and it makes so much more sense to delve deeper into the tool stack we have.

Just consider the amazing tools we have at our disposal for new developers to learn about web development rather than looking at other people’s code in the browser:

  • The MDN Web Docs are an editable resource of everything web, maintained by all the browser makers and with help from many of the large web companies
  • Can I Use gives you detailed information about what works in what browser, links to the standards and explains implementation quirks
  • GitHub is the home of the source-code of many web projects with a whole history of commit messages and explanations how the code works and where and why people added hacks you shouldn’t copy
  • JSBin , Codepen, Glitch and many other interactive development environments help you get started coding things without the pain of setting up all your preprocessors. Something that proponents of a simpler web always bring up as a huge barrier to entry to the web.
  • Browser developer tools aren’t just “look at code” any more. They are fully fledged development environments that give you amazing insight into what’s going on and how things work. They even audit your code and tell you where things go wrong.

All in all I love view source and what it has done to the web. But I also think that in order to build great products these days we should find ways for newcomers to learn about becoming a developer. Not someone who copies and pastes. Learning about code editors, learning about version control, and learning where and how to ask for help are much more important skills.

I believe deeply that free, open source tooling and systems like GitHub and the abovementioned editors are a much better way to teach people to get started with the web than view-source is in 2018. We already live in a more complex world, and we have tools to make that easier.

This is the main topic of my Skillshare class about JavaScript and how to deal with the changes it went through. It is not only about JavaScript, but about the resources I talked about and what tools to use to make your live easier.

I wrote this to make myself more content and happy in this demanding world, and I hope it helps you, too. Old-school developers will find things to try out and new developers should get a sensible way to enter the JavaScript world. Beyond View-Source but without having to be a Webpack expert before you write your first line of HTML.

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)