DEV Community: Vernon Joyce

Is front-end development having a identity crisis? — Part II

Vernon Joyce — Sat, 13 Apr 2019 13:55:26 +0000

Late in 2018 I wrote Is front-end development having an identity crisis as the first part of this series. I was surprised by how popular it was not because of it's obvious click-bait title (guilty); but by how well it resonated with the community. When I gave Part II as a talk early in 2019, the nods in the crowd were almost unanimous --- this is clearly something we need to talk about. Ultimately many developers feel the same: Front-end development as a role has become ambiguous.

A short summary of Part I

Species evolve into many variants or sub-species as a result of natural selection. These sub-species all have different attributes and qualities and ultimately make each of them unique.

Technology is no different. In a way, technology has given rise to hundreds of sub-species of programming languages, paradigms, frameworks and libraries, each with its own unique properties and challenges.

Take JavaScript as an example.

Credit to reddit user u/TheDoctorWumbology

JavaScript has evolved into several massive technologies for both the back- and front-end. The problem with this is that the lines between front-end and back-end, or application and website, or designer and developer, have become blurry. The concept of "front-end development" has almost lost its meaning.

So what is a front-end developer anyway? We need to ask ourselves three questions:

1. What platform are we developing for? --- As developers we have the option of building for multiple platforms: Mobile, desktop, web or server. Front-end traditionally dealt with the user interface of an application but the rapid development of JavaScript has shifted the role into almost all of these platforms.

2. What language are we developing in? --- This shift in platform contributed to the rise of technologies like React and Angular, each with their own set of rules and paradigms. Languages like PHP, Python and C# have also become part of the front-end stack in many organizations as they enable us to build services and APIs.

3. What is my skill level and job title? --- The lack of clarity on platforms and languages result in a mixed bag of job specifications that takes away from our understanding of the title. Some front-end roles require back-end skills and some engineering roles require UI design skills. None of these roles are standardized.

So why does any of this matter?

Ambiguous job specs

In the example below, on the left, the developer is asked to know both Angular and Ionic. Granted there is some overlap between the two technologies, but they are both large frameworks each with their own nuances. Pair this with the graphic design requirement (which has nothing to do with front-end) and you've got yourself a very demanding role.

Example of front-end job posts on LinkedIn. You can read more about my findings in Part I.

The post on the right requires experience in Angular, Java, REST and MongoDB. This role is basically a full-stack, but the salary on offer is measly and the title of this role is front-end developer.

Barrier to entry

These job posts seem harmless, but they actually create a barrier to entry. Recently, a friend wanted to change his career path to something he felt was more future-proof--- so he asked me how he could get into web development.

Honestly I had no idea what to tell him --- the road to master front-end is long and full of terrors. Is there even any benefit in learning HTML and CSS when you're just starting out, considering how demanding entry-level front-end roles are?

I look at this ES6 snippet and honestly question how a junior is meant to memorize and understand this level of code. The reality is that this level of understanding has become an expectation for front-end developers and my view is that this leads to developers getting burnt out.

Burnout

In 2016 I came to the conclusion that I would become obsolete as a front-end developer unless I jumped on the React or Angular bandwagon. I spent some time learning React and realized that I would have to include Node in my stack as well. At one point in time I was learning ES6, Node and React at the same time.

This was hard.

My days turned to 15 hours as I was juggling training and delivering massive projects at work. I was getting up earlier and getting less sleep and the stress of it all compounded. Yes, a year later I knew React and Node, but I was paying the price. This burnout had a massive impact on my personal life and my work and in a way I am still recovering.

Technical interviews

Despite my burnout I was feeling confident in the skills I had learned so I started looking for new opportunities. React at the time was a rare skill in South Africa so I got invited to do interviews fairly quickly. The first interview is always easy, but I was not prepared for the technical interrogation that followed them.

I prepared for these technical interviews but still flunked anyway.

Technical interviews can be hard, especially if you are just starting out as a developer or if you are new to a technology. Technical interviews are important when hiring a developer, but they rely too heavily on our ability to remember technical jargon.

Job titles

Let's say you ace your technical interview and get hired, now your title is *front-end developer. *You walk into your first meeting with stakeholders and the project manager asks the table to introduce themselves. Sally goes first: "I'm the head of digital and I look after the sales funnel of business unit X." Joe goes next and introduces himself as "the product owner and project lead". It's your turn and you mutter "I'm the front-end developer" under your breath.

You instantly lose authority in that room.

The reality is that titles do matter. They carry authority and with that authority comes things like compensation and career growth. Often circumstances force us to accept titles that don't necessarily fit our experience or outputs and this can quickly box us into a role.

How do we solve this?

Now that we understand the problem in a bit more detail, what can we actually do about it?

Firstly we need to educate recruiters and organizations. Organizations often don't understand the roles they are hiring for and we are partly responsible for this.

Company leaders just hear stuff on YouTube or BuzzFeed and slap it into their job descriptions willy-nilly, not realizing that they're seeking a brilliant, made-up unicorn employee.\
A comment by Ruth Reyer on dev.to, Part I of this series

As team leaders, it is our responsibility to educate our organization and ensure that their job specifications are accurate to the role it needs to fill. We are also responsible as developers for questioning our roles and responsibilities and making our leaders aware of these discrepancies.

Lastly we don't challenge recruiters enough. They cast a wide net on platforms like LinkedIn and very quickly dismiss you based on criteria that they don't even understand. I have personally found that recruiters are very open to hearing feedback on their job spec; and this feedback also positions you as an expert.

We need to call roles what they are. Titles are muddy and lack hierarchy which can disable a developer's authority. This has a direct impact on our compensation and career growth.

I am really struggling with where I currently identify as a developer. I primarily do custom-built WordPress sites and am most fluent in HTML, CSS and JavaScript.\
A comment by Jenna Schultz on dev.to, Part I of this series

Organisations and leaders need to make a clear split between front-end, back-end, full-stack and software engineering as titles. This will help us standardize roles and responsibilities; and ensures that compensation associated with roles are fair.

We need to reconsider the way we hire. Technical interviews are a necessary evil, but perhaps we should be testing the problem solving skills of a candidate rather than their memory.

Tech deep divers are off the table for me. I only do conversational style interviews. I try to feel them out as much as possible but if I get in an interview and it slips into deep-dive I just say "I don't know" to everything and end it ASAP\
A comment by Sean Anderson on dev.to, Part I of this series

Test candidates in an environment similar to the one they will be working in. Most developers work in an environment where they can use resources like StackOverflow to solve problems, so why do we expect them to solve problems blindly under immense pressure and scrutiny?

Rather than testing candidates on a phone call, give them a problem they can solve in the comfort of their home with all the tools they'll have access to at work. The problem doesn't have to be easy, but this will give you a good sense of the quality of code they write and their problem solving abilities. If you still need to do a telephonic technical interview, ask them questions that test their problem solving abilities rather than whether they can recite a for loop.

Allow candidates to learn on the job --- lead them to success rather than expecting them to be rock stars from day one.

Lastly remember to cut yourself some slack. We are all eternal students and often face the same challenges --- it takes practice and patience. Sometimes we just need to take a step back and remind ourselves to enjoy the journey.

Follow me

Why designers should understand code

Vernon Joyce — Sun, 03 Mar 2019 10:44:14 +0000

As designers it's easy to get annoyed with developers. Perhaps they can't get the alignment of a button right; or that feature you deemed critical to your UX is just too far down the backlog for your comfort.

The reality is that we get annoyed with developers mostly because we don't understand their world. The same goes for developers' lack of understanding of design --- they get pretty annoyed with us too.

I know this because I've filled both shoes, having spent most of my life designing and developing for web.

We're all guilty of it on some level. As designers we put our blue sky hats on and design to our heart's content without considering the technical implications.

This doesn't necessarily mean we should restrict ourselves; but it does emphasize the importance of sticking to a project scope and ensuring alignment across your team.

With that said, there might be cases where the scope supplied to you just isn't detailed enough. You start inventing functionality or components and often you might sell this to business without any technical consultation. This is dangerous and could easily result in scope creep and a final product that's delayed or over budget.

Another likely scenario is when you're a one man show, designing in isolation. You expect the flat designs you hand over to be pixel perfect but this is hardly ever the case. Your developer does not care about user experience --- and this is completely fair because it's not their job.

Unfortunately many companies are not mature enough in their design approach to avoid these scenarios. Engineering conversations are too often filled with jargon that designers don't understand, resulting in mixed deliverables. Design is also at times brought into the process when the engineering work is already done and when it's nearly impossible to make any design changes.

Bridging this gap might require us, as designers, to know a little bit more about development.

This is not to say that designers need to be full stack engineers, but I'm a firm believer in having a basic understanding of some technical concepts. It will reduce friction, help your team produce better products, and ultimately make you much better at your job.

Data and data structures

Data is the cornerstone of any application. Most applications might use what is called CRUD operations: Create, Read, Update and Delete. These operations are used to manage data, but the kicker is that functions or API calls need to be written for each of these operations, and often for each data set.

In a designer's mind, adding an avatar picture to a profile section seems like a no-brainer. In reality though, a developer needs to write a full set of CRUD operations for this piece of design. Further to this they need to write code to link this avatar up to your profile, and provide a fallback image, and manage where the files are stored on a server. That small design change might have taken you five minutes, but could easily add a day or two to a sprint.

There is also a second part to this: Where the actual data for this profile image is stored. Generally developers would design databases that are easy to scale, but sometimes we might force structure changes by designing new features.

I'm very guilty of this one myself. I designed a web app that allowed you to find location based specials. After some feedback from users I realized that we were missing a very key feature: Customizing the same promotion for different stores. As a designer this problem was very simple to solve: I just had to add some buttons to the back-end and split out one of the admin processes. For the developers however it was a nightmare.

The reality was that the database had to be redesigned and the admin processes rebuilt --- I couldn't afford this and my project fell out of budget and failed. This was not because the developers didn't know what they were doing, but because I had changed the scope.

It's important that we are cognizant of the constraints when it comes to the design of an application's database, as well as the code required to read and write that data. Think about how pieces of data relate to one another; and remember that each piece of text you add to your design needs to live in a database table somewhere.

Asset generation and performance

Most developers take the performance of their applications quite seriously --- I'm obsessed myself and count every millisecond I shave off as a champagne worthy victory.

Performance is key to a good user experience, which means that the performance of your product is as much your job as it is a developer's. It is our responsibility as designers to hand over assets and prototypes that consider the application's performance and this is only possible with a solid understanding of the technology you are designing for.

Imagery is one type of asset that a lot of designers don't hand over properly. It might be tempting to crank up that quality slider to 12 when saving out a JPG but at the end of the day your users will suffer for it. Most WordPress themes for example don't resize images when you upload or use them in production. Yes you can solve this with a plug-in or two, but why not just save it out correctly from the start?

There are some very useful tools for testing image sizes (and services like Google Page Speed Insights even offer compression). Run your live site through these tools and supply your developers with the appropriate compressed images.

Another consideration is SEO. Something simple, such as naming your file in a semantic way, can have a huge impact on your project's search rank. It might seem ridiculous to call that thumbnail 'a-photo-of-an-apple-on-a-cutting-board.jpg' but Google actually reads this metadata.

Lastly this is not only applicable to imagery, but also video. Suggest a third-party service like YouTube or Vimeo --- your developers will love you for it as it does all the heavy lifting for them.

No, I can't improve the performance of your full page transition on IE6.

Another thing we're guilty of is overdoing animation. Sure, that transition might seem smooth and sexy on your iMac Pro but what about the rest of your audience that might be using old laptops? The same thinking goes for other devices like feature phones or older tablets.

Animation can add a lot of bloat to code as developers might need to implement additional libraries to execute it. Additionally it might add unnecessary scope --- advanced shape animation for example would require HTML canvas which is often a specialist skill.

It's important that animation is considered and meaningful. This will ensure that developers are implementing only animation that is relevant to your end-user's experience.

You can read more about creating meaningful animation here, or read more about analyzing performance here.

Technical execution

When wearing my dev hat I sometimes receive designs that are hard to implement; and this is often because the designer does not fully understand what's involved in the implementation. CSS and JavaScript for example has its limitations --- there's just some native mobile features that can't be used for web. Then we also need to consider things like browser support, as well as the effort involved to make a design cross-browser compatible.

With that said, most designs are executable, it's just about finding a compromise between scope and what's best for the user. Having a solid understanding of CSS and the web will help this process along and will reduce friction between you and your developers.

Ensure that your process is agile in nature --- check in with a developer on a regular basis to confirm that your design is executable and within scope.Designing quick prototypes is a great way to showcase your thinking and often your developers might use this to build prototypes of their own. This is great for collaboration and will avoid those design pitfalls.

Lastly, never show final designs to a client without ensuring that they are executable and within your project's scope.

CSS and JavaScript frameworks or libraries

Bootstrap was a turning point for many web professionals. It allowed developers to build websites without designers, and allowed designers to design in a language that developers could understand. In a way Bootstrap was one of the first design systems for the web and allowed for better collaboration between teams.

Bootstrap uses a concept called CSS preprocessing. This allows developers to separate UI styles for different components into their own files. It also allows them to abstract certain properties out as variables, especially if they are repeatedly used in multiple components.

React, Vue and Angular (all JavaScript frameworks/libraries) follow very similar methodologies. These data driven, Single Page Application tools have enabled developers to build highly scale-able web applications that are very modular in nature. Components are separated into their own functional files and often contain the styling (CSS) as well.

Understanding this concept of separation of concerns allow designers to abstract their design work into design tokens, which creates a shared language that both designers and developers can understand.

This shared language is a powerful tool that eliminates jargon from the conversation. It empowers designers to be part of project scoping and sprint planning. There would be no doubt between you and your developer when you ask them to change a button from 'small' to 'large', as the component and it's relevant styling is abstracted out. This ultimately could lead to a design system, which allows design to roll out at scale.

To conclude

I'm not saying that designers need to be hard-core developers, but a little understanding goes a long way. Learn from developers and help them learn from you, so that we can all build better products.

Follow me

How do YOU deal with burnout?

Vernon Joyce — Sat, 12 Jan 2019 07:09:22 +0000

Early 2018 I launched what I considered to be the largest project I had ever worked on. It involved many late nights over the course of 20 months and a painful amount of dev work. I had been the lead front-end developer, the solution architect, a client manager and a project manager. Filling all of these roles was not easy and we would often joke about how empty our lives would be once we launched.

I had no idea.

After an opportunity to reflect in December I realised that eight months later, I had still not recovered from this project.

I am burnt out.

My questions to the community, as I'm sure you've had similar experiences:

Are you burnt out right now?
How do you deal with your burnout?
How do you carry on working when the deadlines keep coming?
How do you recover when you need to pay the bills?
How long did it take you to recover?
How do you keep up with new tech if your day job seems overwhelming as it is?
How do you deal with the depression?

As developers we put unnecessary pressure on ourselves. Pressure to keep learning, to innovate, to keep going. We never stop to talk about the hard things and I don't think there is enough awareness for how badly developers are affected by burnout.

Let's discuss.

What no one tells you about working at corporates

Vernon Joyce — Mon, 29 Oct 2018 09:38:15 +0000

While freelancing I was often told to avoid the big bad corporate. “You’ll be a slave” is something I would often hear from people having “done their time”.

I shared this belief for a very long time.

I had a hard time working for someone else and often left jobs to freelance or run a business. My start-ups would fail and I would struggle to find clients all while trying to pay the bills. I would then lapse back into working for small companies where the cycle would repeat itself and my frustrations would grow.

Even though I felt that the grass was not always greener on the other side, I eventually came to realize that at the very least the grass might be less dead.
Every job or company has its pros and cons and not all of them are created equal. A large corporate, like most businesses, is a complicated organism made up of complicated parts: Culture, hierarchy, politics, infrastructure, processes, regulations… All of these factors give an organization its identity.

Eventually the stress and anxiety of working for myself made the decision to move to corporate much easier. I applied for a developer role with much less responsibility than I currently had — with the goal to lesson my workload.

All I needed was to find a company with the right type of personality— attributes that suited my career aspirations and interests — the right mix of opportunities.

I realized very quickly after starting this new role that I was never prepared to run a business, but more importantly, that I had just walked into a world of opportunity.

Corporates have a lot to offer and I would like to share some of my learnings, as a designer and developer, in an effort to help those that are unsure about whether corporate should be their next move.

Culture and interaction

Culture sits at the heart of an organization and gives it its unique personality. Without culture a corporate would be a soulless factory, and you truly would be a slave. It is what makes Apple and Google such desirable employers; even though they offer completely different working experiences.

As humans we need social interaction and support.

While freelancing I often felt isolated while sitting at home with just my thoughts and pressing deadlines. This lead to frustration and depression and ultimately my work suffered. Working at home requires a lot of discipline and at the time I refused to admit to myself that I needed help.

Corporate culture was what I needed — to be part of something bigger.

There is something meaningful to belonging to this organism, whether you’re chanting a corporate mantra or part of a team vital to executing an executive strategy.

In reality you cannot experience corporate culture at this level as an outsider. There is the surface level stuff that you might get access to as a contractor: casual days, Friday beers, year-end parties… but this happens very rarely and you never really build comradeship with colleagues. Outsiders rarely get to experience the values and behaviors that truly build a company’s unique environments.
Google has an excellent understanding of people’s wants and needs; offering flexible hours, creative freedom, organizational trust and access to incredible people; all of which won them best corporate culture in 2018.

Other cultural activities could include extramural sports teams, meetups, internal talks or sharing sessions, clubs. Google’s award winning culture.

If you still prefer working remotely then you might be in luck as many corporates have started adopting a work from home policy. These policies vary, but some might even allow you to work from home five days a week provided you are available for important meetings. Working from home, for a corporate, also has some advantages over working remotely as a freelancer as you still get to experience the culture on some level.

Not all companies have good culture and a toxic environment could leave you wanting to leave. The good news is that culture is only one aspect of what makes corporates great; and there is still so much more to learn.

Institutional knowledge

It should no longer be a surprise to you; but machines are coming for our jobs. I’m not necessarily talking about Skynet; but the reality is that robotics and AI are improving at an almost uncomfortable pace and we need to be prepared.

One of the ways you could future proof yourself is by acquiring extensive institutional knowledge. A better understanding of how a business works, at scale, could eventually see you move from an execution or production role to a consultative or strategic role — which is much harder to automate.

As a developer I’ve gained copious amounts of institutional knowledge on various topics: IT infrastructure, server maintenance, different programming languages, change management, operations, traffic, business strategy… I am by no means an expert in any of these specialities but I know enough to make critical decisions about my career.

This knowledge could come from various sources, but generally you accrue this over time just by doing your day job and interacting with systems and people. It’s an incredible feeling; piecing together this institutional puzzle as you gain more and more exposure to its different parts.

A good source of information could also be an innovation or research department. Many larger organizations will have one and they will be open to sharing their learnings with others; whether it’s interesting new tech, big data or access to proof of concepts. Collaboration is also a common theme in innovation and research; so don’t be surprised if you spot an opportunity to work on interesting projects for the benefit of the company.

These are only some examples of informative sources you’ll have access to at a large organization. This is not to say you won’t learn anything while working for yourself, but it is called institutional knowledge for a reason. They have more resources, larger budgets and most importantly, many employees to network with.

Networking

Firstly know that you do not need to be an extrovert to network with people in an organization. This is because networking is not about making friends, but allies that align to your values and principals. This is not to say that friendship is not a potential outcome, but it should not be an objective.

The currency of real networking is not greed but generosity. @Ferazzi (Twitter)

The above quote perfectly sums up my experience of networking: It is a result of the value you add to the lives of people in your organization.

Just like you; people have their own agendas and needs. Whether it is career advancement, getting a project over the line or just making it through the day. Strong networks are built by helping other people meet their needs. What you gain in return is their trust; and the likelihood that they will one day return the favor.

This is not to say that you cannot network outside of a corporate environment, but I find it much easier. You have access to thousands of talented people from all walks of life and levels of experience, in a setting that fosters collaboration.

That said, networking might be much harder in some corporates than others, and this is largely dependent on the value it places on hierarchy and the overall corporate culture. You might not have access to other teams or departments due to the institution’s structure— but there are ways around this.

If you have won the trust of your manager, team leader or colleagues they might take you along to important meetings; giving you the opportunity to add value. There is also no harm in asking directly to be invited to a meeting, especially if you know you can add value. You might find your colleagues are quite receptive as long as it is relevant to your field of work and your intentions are honest and clear.

Another way to grow your network is through problem solving. Computer not starting up? No problem, you get to meet someone from your IT department. When you are faced with challenges in your day job you are given the opportunity to interact with people capable of helping you solve these problems and most people are very open to helping others.

Also never underestimate the value of a shared lunch area. It is true that smokers make a lot of friends and for good reason — nothing brings people together like shared values and interests — especially in a captured space.

Lastly, and this might seem obvious, but consistently connect with as people you meet on LinkedIn. Send an invite after a meeting whilst their memory of you is recent and be sure to personalize the request with a message. Stay active by sharing content that is relevant to you and your network to maximize your exposure and grow your reputation.

Building a network takes time but is immeasurably valuable. Be patient; don’t job hop too often and give those relationships time to grow. The partnerships you form at a corporate could very well be the cornerstone for that promotion you want.

Career growth

Chaos isn’t a pit. Chaos is a ladder. Many who try to climb it fail and never get to try again. The fall breaks them. Only the ladder is real. The climb is all there is.

Sometimes the agendas of others might make you feel like you are stuck in Game of Thrones. Quoting Littlefinger might seem dramatic, but in reality if you plan on staying in corporate then the climb might very much be one of your primary objectives.

As you grow your network you will be presented with opportunities to move to new teams or be promoted into new roles. These decisions are often difficult and might require you to make sacrifices. Consider your team and remember that loyalty is often rewarded.

The corporate ecosystem is built to perpetuate success. As you climb the corporate ladder you will get more exposure to culture, gain more insight and knowledge, grow your network and identify more opportunities.

If you are not interested in the political game then perhaps you could take up some of the training and advancement opportunities your Human Resources department offers. Remember that you are an investment and leaders want to see you succeed; which is why large corporates will have budget allocated for training. Other programmes could include mentorship or coaching; or even scholarships for further studies.

Lastly make sure your LinkedIn profile is up to date and professional. When working for a reputable company you might get bombarded by recruiters wanting a piece of you, especially if your skills are in high demand. This is not to say that you should be entertaining every single offer; but grab the opportunity to grow your network and keep an eye out for offers you can’t refuse.

Other benefits

It goes without saying that there are many other benefits to working at a larger company. I’ve covered some of the not-so-obvious ones, but there are plenty more:

Competitive salaries

Yearly compensation
Additional leave (including family responsibility)
Subsidized services and products (food, dry cleaning, medical etc.)
On premise services like grocery stores or gyms

These are only to name a few; all aimed at making it easier to maintain a work life balance.

What’s next?

If you find yourself questioning what you do, like I did, you might consider broadening your horizons by applying to a corporate. Or perhaps you are already working at one and you weren’t aware that there truly is greener grass on the other side.

Many people eventually leave corporates to build start-ups, businesses or very successful freelance careers. Could they have done it without their corporate experience? Perhaps.

My question is, what do you really have to lose?

This article is purely based on my personal experiences and biased opinions — I would love to hear your views down in the comments.

Vernon Joyce, a full-stack unicorn

Is front-end development having an identity crisis?

Vernon Joyce — Sun, 09 Sep 2018 12:53:53 +0000

Courtesy Adobe Stock

Does front-end development as a we know it still exist; or has the role evolved into something we no longer recognise? As with evolution in nature, the evolution of "front-end" has resulted in several distinct flavours --- and in my opinion --- an identity crisis.

What is a front-end developer anyway?

Traditionally speaking the front-end could be defined as the UI of an application, i.e. what is client-facing. This however seems to have shifted in recent years as employers expect you to have more experience, know more languages, deploy to more platforms and often have a 'relevant computer science or engineering degree'.

Frameworks like Angular or libraries like React require developers to have a much deeper understanding of programming concepts; concepts that might have historically been associated only with the back-end. MVC, functional programming, high-order functions, hoisting... hard concepts to grasp if your background is in HTML, CSS and basic interactive JavaScript.

This places an unfair amount of pressure on developers. They often quit or feel that there is no value in only knowing CSS and HTML. Yes technology has evolved and perhaps knowing CSS and HTML is no longer enough; but we have to stop and ask ourselves what it really means to be a front-end developer.

Having started out as a designer I often feel that my technical knowledge just isn't sufficient. 'It secures HTTP requests and responses' wasn't deemed a sufficient answer when asked what an SSL certificate was in a technical interview for a front-end role. Don't get me wrong, these topics are important, but are these very technical details relevant to the role?

I will be occasionally referring to front-end development as FED from here on.

The problem

This identity crisis is perpetuated by all parties: organisations, recruiters and developers. The role has become ambiguous with various levels of responsibility, fluctuating pay scales and the lack of a standardised job specification within the industry.

While looking at the job market you might find that organisations expect employees to be unicorns and fill multiple shoes. Recruiters also could have unrealistic expectations in terms of the role which is often supplied by a Human Resources department with little understanding of what they are hiring for. Lastly developers compound this problem ourselves: they accept technical interviews as they are and should we get the job we place ourselves under unnecessary pressure to learn the missing skills, instead of challenging recruiters and organisations on what it actually means to be a front-end developer.

Compare the below job posts on LinkedIn, both titled 'Front-end Developer'. The roles are vastly different: on the one hand the developer is expected to know Flux architecture and unit testing while on the right they are expected to know Java and MongoDB.

Comparing two roles on LinkedIn, both labelled "Front-end developer"

Both of these roles are vastly different; and clearly lack a definitive scope or the role.

Why it is important to standardise the role

Evening out the pay scale: front-end engineers won't get paid what FEDs should and vice versa.
Alleviates pressure; allowing developers to either focus on engineering products or on creating rich interactive web experiences
It creates specialists; developers who are really good at CSS, HTML and interactive JavaScript
Makes job hunting less stressful when it comes to technical interviews and job specifications

Separation of concerns

In order to define the role we have to strip out all the roles that could be considered above and beyond the scope of a FED. The web developer role, for example, should not be confused with the FED role as the one builds applications and the other builds experiences. Other examples include front-end designer, web engineer, back-end web developer etc.

To distinguish these roles we could look at four criteria:

The developer's canvas

If we were to make the assumption that the primary context for front-end is the browser --- where would that leave PHP or C# developers on the spectrum? PHP is a good example; yes it runs on a server but ultimately still delivers data to a UI (i.e. the browser). Both JavaScript and PHP are scripting languages that don't require compilation. Is a PHP developer then considered a front-end developer or a back-end developer?

Tools like Github's Electron allows a developer to build cross platform desktop apps from HTML, CSS and JavaScript. Similarly tools like Adobe Phonegap make it possible to compile HTML pages with JavaScript to native mobile applications. This essentially enables an intermediate front-end developer to build and publish mobile or desktop apps. Could app development then be added to the scope of a front-end developer's responsibilities?

The lines between back-end and front-end became blurry somewhere between JQuery and Node and ever since it's often expected for front-end developers to know Node and accompanying packages like Express. These are clearly back-end technologies, so why are we adding them to a FEDs job specification?

Before we can standardise the role we have to agree on what the front-end developer's canvas is. In my view, this is confined to the UI of an application and primarily runs in a browser --- the role should not be concerned with building any server side functionality.

The chosen language

A second criteria to consider might be a developer's chosen programming language. It is possible to build website infrastructure in languages like Python and C# which begs the same question as before --- could Python, PHP and C# be considered a front-end language?

The below example asks for PHP as a required skill where the other expects the developer to know TypeScript.

Comparing the skills required for two roles on LinkedIn, both labelled "Front-end developer"

JavaScript can now do much of what PHP and Python can do; with popular libraries like TensorFlow becoming available to JS developers. Another example includes TypeScript (as above), which brings static typing to JavaScript from languages like Java. Where do we draw the line then in terms of what is considered a front-end language or framework?

Which frameworks or libraries then should be part of the role's scope if we are excluding PHP, C#, Java etc? JQuery for example is a the perfect tool for building interactivity for the web, where most front-end developers might argue that it's better to learn Vue.

Libraries like React on the other hand requires a developer to learn concepts that traditionally were not associated with the front-end: setting up webpack and transpilation, deployment processes, understanding high-order components and just for fun you might throw in state management with Redux. The list grows quickly; and although this all uses JavaScript as a language the understanding that comes with it is often very different.

Many back-end developers have told me that they find CSS very difficult and I agree --- CSS is hard! We forgive back-end developers for not knowing CSS and interactive JavaScript; why then is there an expectation for front-end developers to know back-end technologies?

The question we should ultimately be asking is whether a front-end developer should be dealing with functional or data driven components at all. In my view, the role's language choice should only be HTML, CSS and JavaScript (limited to front-end libraries), primarily used to build interactive components or web projects that consume data from services where necessary.

The skill-level

When does a front-end developer transition into a full-stack developer or a web developer?

Distinguishing this becomes really easy when considering the canvas as well as the chosen language. A full-stack developer is a developer that understands both front-end and back-end (i.e deals with more than one canvas). A web developer is a developer that can work in multiple frameworks, libraries and languages to build rich data driven applications. Most FEDs will then most likely move from an intermediate FED role to a senior full-stack, engineer etc. role.

Is it then possible to be a senior front-end developer when considering our role definition up to now? My argument is yes. Simply look at any winning website on Awwwards and you'll quickly agree that this level of interactivity requires a very good understanding of the DOM and DOM manipulation via JavaScript. FEDs also then have an opportunity to focus on learning libraries that build interactive features (for example HTML canvas, WebGL) as opposed to back-end libraries or frameworks that takes them away from what got them started as a FED in the first place.

Other specialties

The last factor to consider are all the additional requirements that come with front-end roles. I consider this 'baggage' mostly because these requirements often get thrown into the mix in an ad-hoc fashion.

A good example of this is MongoDB (which was a requirement in the listing mentioned earlier). Previously database administration or architecture was a role in itself, so why now are we expecting FEDs to have this skill set on top of everything else?

Another example from an earlier screenshot is the listed graphic design requirement. Personally I am a big advocate of developers understanding design, but expecting them to have it as a skill on top of their other FED skills changes the role into something else (perhaps a front-end designer or full-stack designer).

When considering the added responsibility that comes with having all this knowledge, we have to ask ourselves whether adding them into the mix only complicates the landscape. If today I decided to bring React into my organisation, the developer they choose to replace me with would have to know React as well. If the new developer then decides to add Redux to the mix... well you understand where this is going. To make matters worse, they will keep on hiring front-end developers regardless of the technology used because that is the role required by the department.

So with great power does come great responsibility and it is ultimately up to us as developers to use technology responsibly. Consider the operational impact of a technology stack change and understand that you might be perpetuating an existing problem.

Defining the role

Now that we've unpacked what it means to be a front-end developer, we could write the following job description:

A front-end developer is responsible for building interactive user interfaces or experiences for the web using HTML, CSS and JavaScript.

Let's keep things simple --- a FED should not need to understand functional programming or how SSL works on a micro technical level. This is not to say that they shouldn't learn these concepts; but at the very least it shouldn't be an expectation.

I feel that it is important that we collectively address the confusion surrounding the roles in the development community by helping the next generation of front-end developers understand what it means to be a FED.

This article is purely based on my personal experiences and biased opinions --- I would love to hear your views down in the comments.

Vernon Joyce, a full-stack unicorn.

Give me some love on my other channels

LinkedIn
Medium
Twitter

A UX review framework anyone can use

Vernon Joyce — Wed, 20 Jun 2018 14:29:06 +0000

As connected products are integrated into more aspects of our day to day lives, UX will be responsible for translating strategy into intuitive experiences.

Forbes

The demand for UX has become clear as organisations rush to create products that put client needs before business needs. These organisation often have large UX and design teams who focus solely on providing the best possible experience to their customers.

But what if you or your business cannot afford to hire a UX designer to review your product or service?

My goal for sharing this framework is to allow anyone to do a UX review; whether you are a UX designer or not. You can use this framework to analyse a product or service* or analyse a piece of work for a potential client. You could even use this to review your own work as the tools and techniques I use leave little room for bias.

*Although this framework can be used for any type of product or service, it will primarily focus on web.

**There are plenty of dev goodies in this article - it's not purely meant for designers.

Objectives of the review

It's important to start your review by positioning your objectives. This sets the tone and ensures that both you and your stakeholder have the same expectations --- whether you are presenting your review or sending it via email.

Some objectives or outcomes could include:

Identify opportunities
Substantiate design changes
Identify technical issues
Discuss UX improvements

These objectives will mostly relate to your initial briefing --- why did your client want you to do a UX review in the first place?

Business objectives

Business objectives are what your client is trying to achieve. Sometimes objectives can easily be ascertained by yourself but they could also require additional research. In the case of research it depends on your client --- sometimes their objectives are obvious but often there are deeper needs that need to be brought to the surface through further inspection.

Unpacking these objectives is important --- let's take *increasing sales *as an example. Are they trying to sell more of a specific product or perhaps drive in-store traffic? These details are important as it makes your outcomes much more tangible and measurable. It is much easier to credit a sales increase of a specific product to a UX improvement, than to match a sales increase of a thousand products to an objective that has not been properly defined.

These objectives can be unpacked by conducting interviews with your client and their stakeholders and additional objectives could also be identified through market research. A simple survey through Survey Monkey can provide valuable insights if you have access to your stakeholder's clients.

Lastly, state these objectives in your review to remind your client of the problems you are trying to solve. This will reaffirm your thinking throughout the review and give your ideas credibility.

Personas and userflows

Now that you understand the business' needs, it's time to look at the user's needs. A popular way of unpacking user needs is by creating personas or persona sheets. In short a persona is a fictional user with needs, aspirations and desires that are usually linked to objectives within their lives.

Take Sandy for example. She is a middle-class professional female with a family of two. She likes learning about technology, watching documentaries and spending time with her children. Sandy is an ideal customer for a geeky toy shop, where she can purchase an electronic toy that both her and her children can enjoy.

Creating personas can be daunting but become an invaluable tool. Personas can be set up through research along with a firm understanding of you or your stakeholder's business objectives. Shane Williams offers a comprehensive look at creating personas in Getting started with creating personas --- questions to ask.

Now that we know who your users are, it's time to look at the steps they would take to achieve their goals. This can be done by creating userflow diagrams. These diagrams demonstrate sample user journeys based on your user's objectives and can often be combined with business objectives for a full client experience view.

Example of user flow diagram

There are many ways to create these diagrams, whether using sticky notes or an online tool like Draw.io. There are no rules when it comes to designing these diagrams --- but it is important that your diagrams are easy to follow and read-able.

Working with data

Data is the cornerstone of a good UX review and without it you might find it difficult to back up your findings. Google analytics offers a great starting point for user interaction data, provided you know what you are looking for.

Something as simple as a drop in traffic on a given day could indicate a problem --- perhaps users had a negative reaction to a new feature or maybe you posted something on social media that got negative press.

Device information (such as mobile vs desktop traffic) could also be meaningful when deciding on which device to focus your usability assessment.

Event tracking in Google Analytics provides another helpful source of information assuming it has been set up correctly. CrazyEgg is a great alternative should you not have the expertise to set up event tracking in GA as it offers heatmaps for both clicks and scroll on different devices.

The behavior flow report is also invaluable and offers insights into the journey users take in the form of a flow diagram. It provides data on drop-offs, sessions and more with the ability to highlight or analyse specific user paths.

Example of Google Analytics' behavioural flow diagrams

Conducting System Usability Scale (SUS) surveys is also a handy way to quickly gauge the usability of a system through user feedback. SUS tests can be conducted on products, websites, apps or software and provide a scaled result regardless of the volume of feedback. The SUS survey's data is also useful going into the usability review.

Lastly the persona sheets you set up in the previous section are also an excellent source of data. Keep your user objectives in mind when examining any of these data sources and you might find behavioural patterns that indicate a gap in the user's journey.

You or your client might not always have data tools set up. In these cases my advice would be to postpone the review until you have meaningful analytics to work with. Installing GA is quick and easy and should give you relevant insights after only a month.

Usability review

Usability rules the Web. Simply stated, if the customer can't find a product, then he or she will not buy it.

Jakob Nielsen

Usability speaks to the core of the review --- is the product usable?

It's time to make some assumptions about the usability of your project based on business and user needs. Step into the shoes of your users using your persona sheets, userflows and analytical data. Start using the application or service on different devices, browsers or operating systems while following your userflows. You will quickly pick up on journeys that are possibly frustrating or pieces of functionality that do not help you achieve your objective as the user.

You might also come across design flaws, broken or confusing components or responsive issues. Jot all of these potential problems down while taking screen shots. Once you have moved through the project as a user, step into the shoes of the product owner and go through the same process.

Your next challenge is making the feedback easy to understand when consolidated. Remember --- your client might not have any understanding of UX or design and it is your job as a UX reviewer to make the feedback concise. Explain your thinking verbally in detail if necessary, but keep your written feedback short and to the point. It is also very important to make sure that the feedback is not seen as a list of problems or issues but rather as opportunities for improvement.

Lastly, do not go into solution mode yet. At this point you are only identifying usability problems. I like to consolidate my feedback into buckets:

1. User journeys

This should cover any problems relating to a user's journey. If you have trouble convincing your stakeholder of these problems, try placing them in the user's shoes. Some examples of user journey flaws could include:

Information needed by a user is too low down a page
Important pages are hidden too deeply within the information architecture
Information is unnecessary and does not provide value to a user
Too many clicks are required to make a purchase
Inconsistent user journeys
Important information sits below the fold

2. General

What are the consistent problems across the product or service? List anything that is not specific to a journey or device.

3. Design

Having a design background is very useful in this section of the review, but is not necessarily a requirement. There are some aspects of design that are generally obvious to spot:

Design inconsistencies (i.e buttons are different sizes on different pages)
Problems with alignment
Poor page hierarchy

4. Mobile

The accuracy of your mobile review is very dependent on the different types of devices you use to test (both tablet and smart phones). These issues could include:

Responsive problems (i.e not mobile friendly)
Scale problems such as fonts being too small
Pinch or zoom is required on some pages

5. Desktop

For the most part you would have covered any issues on desktop in the other sections, but from time to time there might be issues that are desktop specific. Also keep your analytics in mind --- if your traffic is primarily mobile you might want to skip over this section.

Accessibility review

Accessibility is often overlooked by both developers and designers --- I am guilty of this myself. It has however become increasingly important to consider disabled users as we become driven by digital. Something as simple as green text on a red button could completely ruin a colour-blind user's experience and result in a lost sale or lead.

Accessibility covers several aspects including colour, font size, font types, descriptive text or alt tags. It is important to consider all these design and technical aspects as they might affect the user's experience.

A tool I often use for testing accessibility on the web is Google Lighthouse. Lighthouse is available via Chrome developer tools and offers detailed feedback on the speed, progressive web app features, accessibility, best practices and SEO of a website.

Google Lighthouse results

Not only does it offer solutions, but also substantiates suggested changes making it a powerful tool in a UX reviewer's arsenal.

When a button doesn't have an accessible name, screen readers announce it as "button", making it unusable for users who rely on screen readers.

Example of Google Lighthouse feedback

Eightshape's colour contrast grid is a useful tool for analysing the accessibility of a digital colour palette while Colorsafe offers an easy way to find passable colour combinations.

Results of Eightshapes' color contrast test

Technical review

Whether or not you include the technical review in your presentation depends on the way you position it as well as how technical your audience is.

What makes the technical review helpful is that more often than not small code changes can make a big difference in conversion rates and overall user experience.

1. Performance / speed

A score from Google Page Speed Insights

A great tool for analyzing website speed is Google's better-known Page Speed Insights. PSI offers some quick tips for improving your page speed which includes caching of assets, optimizing images and more for both desktop and mobile. The suggestions can at times become a bit technical, but Google offers links to helpful articles that explains each suggestion in detail.

Performance can also be analysed using Google Lighthouse (mentioned earlier). Lighthouse provides a lot more detail than PSI and also makes suggestions based on newer technologies (like the HTTP/2 standard).

2. Best practices

Best practices deal with whether or not a project is following standards for a given device or medium. A good example of this is when print standards creep into the web, such as forcing line breaks in headlines, which is bad practice for responsive web projects.

Lighthouse is also a good tool for best practice suggestions; but knowing what is considered best practice often comes down to your experience with the channel or device you are reviewing.

3. SEO

SEO is not often considered when looking at the user experience of a web product--- but it should be. SEO deals not only with your rank, but also your search appearance. If your page does not have an enticing title and description you lose every opportunity to bring that user into your website. Often some of the problems you solve for when it comes to accessibility will impact your SEO as well (such as making alt tags more descriptive).

Lighthouse provides some high level feedback on SEO, but for a more detailed view I would recommend Moz.

SEO Software, Tools & Resources for Smarter Marketing\
Backed by the largest community of SEOs on the planet, Moz builds tools that make SEO, inbound marketing, link...moz.com

Opportunities

The next step is to look at how you or your client can close some of the gaps in their user's experience using the wealth of data gathered from the review. These suggestions could be based on feedback from your review or opportunities you identified while using the product, for example:

Adding related articles to existing pages will allow a user to continue his journey through the website once they finish reading an article
Reducing the length of the form could improve its usability which might lead to additional leads

Be careful of making swooping statements like "Adding a banner area will increase traffic*". *An opportunity should imply the possibility of improvement and not a promise thereof.

Metrics

Implementing a solution to an identified UX problem might not be enough --- you also need to be able to measure its success. This can be done by setting metrics for specific action points.

A good metric needs to be tangible and achievable. "Increase sales" for example is not a tangible metric. How would you accurately measure that and more importantly correlate it to a UX change?

Break your metrics down, give them a deadline and bring them back to your objectives and identified opportunities:

Decrease the bounce rate of X page by 5% by adding related articles
Capture 5 more leads on X page per day by making the form easier to use

Your client might also want to set their own metrics. In these cases make sure that their expectations are reasonable and achievable.

Next steps

Discuss next steps with your client even if you might not be responsible for implementation. Without actionable points the review is bound to become a coffee-stained desk-drop. Creating a list of actions or tasks along with their priority and metrics is a good starting point and will provide your stakeholder with enough guidance to start implementation on their own.

Who knows, you might even become that implementation partner or a UX designer within their team.

I hope you found this framework useful --- would love to know more about your experiences in the comments below. Thanks for reading.

Originally posted on Medium

Integrating WordPress into DialogueFlow with Node JS

Vernon Joyce — Fri, 29 Dec 2017 18:58:47 +0000

The WordPress API has opened many doors for developers – particularly when it comes to managing content for other web applications and mobile apps. In this instance, we’ll be looking at how we can integrate the WordPress API into Dialogflow with Node JS to deliver content to Facebook messenger. This tutorial explains some basic concepts, but working knowledge of Node and Dialogflow will be beneficial. PS I've written this for intermediate devs, as an intermediate dev, feel free to skip over some of the easy concepts

Before you get started, ensure that you have done the following (links are available):

Installed a working version of Node JS
Installed the Heroku CLI
Created a new Node project
Created an empty GIT repository
Set up a Dialogflow account
Installed Postman or JSONview for Chrome (recommended)
Have access to a WordPress blog to pull content from (I am using this blog as an example)

Setting up the intent

Set up our tags as entities

In order for our chatbot to understand what type of content our users are looking for, we need Dialogflow to use its natural language capabilities to understand the tags within a user’s intent. To do this, we will set up an entity. Entities are types of content within a message that allows our bot to have more context; for example a place or a date. We need to create our tags as entities as we will later be using them to pull specific content from our WordPress blog.

Start by clicking on the Entities tab to the left of the Dialogflow console. Ensure that your entity has a semantic name (like tags) and tick the Define synonyms box. Add each tag as a new row: in the first column, add the tag number (or ID) and in the second column list all of the different synonyms for this tag. The tag number will make it easier for us to pull posts by tag from our webhook – you can get this by editing the tag in WordPress, or calling the API URL to get all tags. Once you’re done click Save and head over to the Intents tab.

Create an intent for content delivery

We’ll now set up an Intent to enable us deliver content to our users. A good strategy is to name your intent something similar to what the user might ask – this is especially useful when you have more than 10 intents. Next we add an example of a user’s input. In this case, we are using I want to read more about development. In order for Dialogflow to understand development within context of the user’s message, we need to map the word to our entity. Select the entire word and the entity menu should automatically open up – scroll down or use the filter to select the tag (@tag) entity that we created.

Training our bot

If we now send a I want to read more about development as a test message within the right-hand message console, you will notice that Dialogflow returns an empty message, with a set Paramater of Tags and a value of 22 (which is the ID for the development tag). If we change our message to I want to read more about content; we get a similar response but the value of our tag parameter will be content. This means that Dialogflow is able to understand our message and discern that we want to know specifically about development or content.

If we however change our message to I want to know more about web design, Dialogflow will in most cases not be able to understand which tag we are referring to. This is because our bot needs some additional training – which means we need to add more possible user messages. These could include I want to know more about, tell me more about, I’d like to read about, can you help me with. There’s no limit to the amount of scenarios you can add to Dialogflow; but 10 usually does the trick. As you add these messages you might find Dialogflow picking up the entities automatically, which just means that your training is working.

Setting an action and making tag a required entity

One of the requirements for webhooks is having something to identify our intent by. This can be done in many ways, but my recommendation is to use the action property of an intent. Dialogflow will take the entire intent’s payload (a JSON object) and send this to our webhook. We can then access the payload and check the value of the action key and ultimately use this to build our logic. I’ll show you how this works later, but in the meantime, just give your intent an action by entering it into the action input field. Call it something semantic – in my case I am using get.wp.content.

Next we need to ensure that our bot always has some context when it sends off that payload to our bot. If you were to ask your bot something like I want to know more you will notice that it is unable to pick up our Tag entity – because our message doesn’t contain one. To fix this problem we need to set our tag entity to required by ticking this box underneath the action input field. We also need to give our bot a way to ask for this information, and this can be done by selecting the prompts column and adding a prompt for more information. Good examples include What do you need help with? or What is your profession?

Once done, save your intent and we should now be ready to move on to building our webhook and integrating it into a WordPress blog.

Creating a webhook

There are plenty of repositories available online for pre-built webhooks; but for the purpose of this article we will be building one from scratch. I will provide code samples, but this is not necessarily a Node tutorial, so if you have any questions leave a comment. You are also welcome to fork the repo for this project.

Setting up our project

For our webhook, we will be using the express, body-parser and request packages. To get started, we will install these packages via npm install:

npm install express body-parser request

Once you have these packages installed, you can set up the rest of your project by organizing assets. I will be saving all of my code (except server.js) in a lib folder; this will help us segment our functionality to make our code more readable and reusable. Lastly don’t forget to add node_modules to .gitignore!

To get started, create a new file in your project root called server.js. This will house all our express code and will be our default script. Open up server.js and start off by importing the express and body-parser modules – we will be using ES6.

// Modules
const express = require('express');
const bodyParser = require('body-parser');

Next we declare app as a new express instance, and add body-parser to it as a middleware to enable us to read our JSON payload from Dialogflow.

// Express set up
let app = express();
app.use(bodyParser.json());

Once the express app is set up, we need to start our own server. Express requires us to set a port number in order to start a server; but because Heroku assigns ports at server runtime; we will need to get the port number from the Heroku environment. To achieve this, we use process.env.PORT with a default to 3100 should no environmental port exist. You can read more about this here. Your code should now look like this:

// Modules
const express = require('express');
const bodyParser = require('body-parser');

// Set port for server
const port = process.env.PORT || 3100;

// Express set up
let app = express();
app.use(bodyParser.json());

// Start server
app.listen(port, () => {
    console.log(`Listening on port ${port}`)
});

That’s it for now – we have everything we need to start writing our webhook.

Writing our webhook route

Dialogflow requires a route in order to successfully communicate with our webhook. We will be creating a new post express route to handle this. I am naming this route /webhook to make our code more scalable, should we want to add more routes later. In the lines following the loading of the body parser middleware, create a new post route:

app.post('/webhook', (req, res, next) => {  
});

Inside our webhook route, let’s get the action from our Dialogflow payload. If you are unsure of how the payload is structured, you can view the JSON structure within Dialogflow when sending a test message on the right-hand side of the console. In our JSON object, the action is within the result object of our payload. We need to access this by getting the body of our request object – the request object is any information sent via post to our webhook route. Our body parser middleware will allow us to get the body from the request object, which we’ll store in a new variable called action. Let’s also declare another empty variable called message (which will be the message our webhook sends back to Dialogflow).

let action = req.body.result.action;
let message = '';

The last step is to send a response back to Dialogflow by using our routes response object – this is done by calling res.send. We will be sending back a JSON object containing our message, which forms part of Dialogflow’s fulfillment lifecycle. We will also use a simple if/else ternary to check whether or not we are hitting the get.wp.content action we set up in Dialogflow. Our server.js file should then look something like this:

const express = require('express');
const bodyParser = require('body-parser');

const port = process.env.PORT || 3100;

let app = express();
app.use(bodyParser.json());

app.post('/webhook', (req, res, next) => {

    let action = req.body.result.action;
    let message = action === 'get.wp.content' ? `Hey, our webhook is connected!` : `Sorry, I didn't get that`;

    res.send({
        speech: message,
        displayText: message,
        source: 'wp-webhook',
    });

});

app.listen(port, () => {
    console.log(`Listening on port ${port}`)
});

Connecting our webhook

Now that our base webhook is done, it needs to be uploaded to Heroku. Heroku offers free hosting for Node (and many more) applications, with the option to scale when necessary which makes it a great option for deploying our webhook. Dialogflow requires webhooks to be hosted on https, which Heroku takes care of too.

First off, let’s cd into your project folder and create a new Heroku app by running heroku create within terminal or command prompt. If you are asked to log in, use your Heroku credentials and retry the command. Once created, you will be presented with a unique Heroku url which is the link we’ll be using later within Dialogflow. Next we add all our files to our git repo, and commit them. The last step is to push these files up to our Heroku app by running git push heroku master.

heroku create
git add .
git commit -m "Init webhook"
git push heroku master

Once you push up your code, it will run all the necessary build steps and once done you should see Build succeeded! within the console. You can now test your application by running heroku open, which will open your heroku app. You should see an error message; Cannot get /; this is normal as we haven’t set up this route.

Now that our webhook is working, we need to enable fulfillment within Dialogflow. To do this, click on the fulfillment tab in the left-hand menu, and on this page enable it. Paste your webhook url (you have to include /webhook) into the first input and save.

The final step is to go into our intent on Dialogflow and enable Use webhook under the fulfillment section of the page (right at the bottom). Click save and wait for the agent to train. Now when you send I want to read more about development to the testing console on the right-hand side, you should get Hey, our webhook is connected! as a response!

Getting WordPress articles

For this next part, I’d recommend you use something like Postman to have a better understanding of responses from the WordPress API look like. If you don’t have your own blog to pull content from, you can use Diginauts (as per this demo) as it gets a low amount of traffic. To do some testing, hit http://yoursite.coma/wp-json/wp/v2/posts in Postman (or a browser) and you should see a JSON object with a list of posts from that blog. This is how all of our posts will be structured and we will later use this information to format our Facebook messenger response.

We can also get posts with specific tags, if you hit http://yoursite.com/wp-json/wp/v2/posts?tags=22 you’ll see only posts tagged with the development tag. This is great news as it means we can now use our Dialogflow tag parameter to get the posts we need.

Setting up the API request

Back in our project, I’m going to create a new folder called wordpress in our lib folder, and create a new file called wordpress.js. The first thing we need is to load the request module we installed earlier, as we will be making an API request. I am also going to declare a new variable with a link to the API.

const request = require('request');
const api = 'http://yourblog.com/wp-json/wp/v2/';

We now want to set up a function that will allow us to load posts from the WordPress API. Our function will take two arguments, the tag we want to fetch content for as well as a callback for when our API call is completed.

let getPosts = (tag, callback) => {
}

Now we want to construct the URL for our API call. There are various ways to do this, and ideally you want to refactor the getPosts function by adding more logic to our API URL, but for now we’ll keep it simple. Our API call has three requirements: we will firstly be hitting the /post route of the WordPress API which will allow us to get posts. Secondly, we need add a URL parameter to only get posts of a particular tag by its ID. Lastly, we want to add the _embed parameter as this will include the featured image in our payload. I will embed all of these using ES6 template strings.

let getPosts = (tag, callback) => {
    let url = `${api}/posts?tags=${tag}&_embed`;
}

Handling the error and not found cases

We are now ready to fire a request to the WordPress API using the request module. Request takes two arguments: our API URL (or an object with data) and a callback function with an error, response and body argument. Within an I’d statement we will handle the error and success case. For now, let’s call our callback if an error occurs by adding a user-friendly error message and returning the error.

let getPosts = (tag, callback) => {
    let url = `${api}/posts?tags=${tag}&_embed`;
    request({url}, (err, res, body) => {
        if (err) {
            callback('Sorry, there was an error getting posts from our blog', err)
        } else {
        }
    });
}

For our not found and success cases, we need to firstly parse our response’s body as the WordPress API will return an array of stringified JSON objects and assign this to a variable. Once we’ve parsed the response we need to check the amount of items in our array – if the array is empty no articles were returned so we can let our users know via a friendly message.

let getPosts = (tag, callback) => {
    let url = `${api}/posts?tags=${tag}&_embed`;
    request({url}, (err, res, body) => {
        if (err) {
            callback('Sorry, there was an error getting posts from our blog', err)
        } else {
            let posts = JSON.parse(body);
            if (posts.length === 0) 
                callback(`It doesn't seem like there's any content available on this topic`);
            }
        }
    });
}

Handling the success case

Add an else statement to our check for the array length to deal with the success case. The WordPress API returns a lot of data that we won’t be needing for our Facebook cards, so we need to map the data into a new array and take only the information we need. At the same time, it would be beneficial to structure our array in the format required by Facebook to show cards within messenger. Most of the information we need can be found by traversing our API response (you can use Postman for a better view of what this response looks like). For the subtitle we need to strip out all HTML tags and entities to ensure we send a clean string to Facebook as the API does not return a clean string – we can do this with regex. Lastly, we need to get our featured image. This is embedded very deep into our API response and you have to use bracket notation when referencing wp:featuremedia as it contains a colon.

The last thing we need to do for our success case is add a text message to our bot’s response as it would be odd if our users only got a list of articles. We can do this by adding a custom message at the beginning of our formattedPosts array using unshift. Once this is done, we can call our callback by setting our first argument as undefined (as there was no error) and setting our second argument equal to formattedPosts. Export getPosts via module.exports and we’re done with our wordpress module.

const request = require('request');
const api = 'http://diginauts.co.za/wp-json/wp/v2';

let getPosts = (tag, callback) => {
    let url = `${api}/posts?tags=${tag}&_embed`;
    request({url}, (err, res, body) => {
        if (err) {
            callback('Sorry, there was an error getting posts from our blog', err)
        } else {
            let posts = JSON.parse(body);
            if (posts.length === 0) {
                callback(`It doesn't seem like there's any content available on this topic`);
            } else {
                let formattedPosts = posts.map((post) => {
                    return {
                        type: 1,
                        platform: 'facebook',
                        title: post.title.rendered,
                        subtitle: post.excerpt.rendered.replace(/<(?:.|\n)*?>/gm, '').replace(/&[^\s]*/, ''),
                        imageUrl: post._embedded['wp:featuredmedia'][0].media_details.sizes.listing.source_url,
                        buttons: [
                            {
                                text: 'Read more',
                                postback: post.link
                            }
                        ]
                    }
                });

                formattedPosts.unshift({
                    type: 0,
                    platform: 'facebook',
                    speech: 'Sure, here are some helpful articles'
                });

                callback(undefined, formattedPosts);
            }
        }
    });
}

module.exports = {getPosts};

Tying it all together

Since our post data is ready to be consumed, we can go ahead and send a response back to Dialogflow from server.js. First, let’s import our wordpress.js module using require and remove our message variable as well as the existing code for sending a response. Create a new variable for the tag we will be passing to our getPosts function and set this equal to the parameters property of our Dialogflow payload.

const express = require('express');
const bodyParser = require('body-parser');

const wordpress = require('./lib/wordpress/wordpress');

const port = process.env.PORT || 3100;

let app = express();
app.use(bodyParser.json());

app.post('/webhook', (req, res, next) => {

    let action = req.body.result.action;
    let tag = req.body.result.parameters.tags;

});

app.listen(port, () => {
    console.log(`Listening on port ${port}`)
});

We are now able to call our getPosts function via the wordpress module we imported. This function will take our tag as an argument followed by our callback function. Our callback function has its own parameters: an error message and our post content. If there is an error message present, we can send that error message as a Dialogflow response to the user by using the same JSON format we used earlier. For our success case (i.e errorMessage is undefined) we can send our post content to Dialogflow, but this time we will be sending it via the message property. The message property contains an array of messages for different platforms and types and since we specified this array in wordpress.js, we can simply send off our postContent variable. Leave speech and displayText empty as we won’t be needing a generic response.

const express = require('express');
const bodyParser = require('body-parser');

const wordpress = require('./lib/wordpress/wordpress');

const port = process.env.PORT || 3100;

let app = express();
app.use(bodyParser.json());

app.post('/webhook', (req, res, next) => {

    let action = req.body.result.action;
    let tag = req.body.result.parameters.tags;

    wordpress.getPosts(tag, (errorMessage, postContent) => {
        if (errorMessage) {
            res.status(400).send({
                speech: errorMessage,
                displayText: errorMessage,
                source: 'wp-webhook',
            });
        } else {
            res.status(200).send({
                speech: '',
                displayText: '',
                source: 'wp-webhook',
                messages: postContent
            });
        }
    });

});

app.listen(port, () => {
    console.log(`Listening on port ${port}`)
});

Push this code up to Heroku and test your intent within the Dialogflow console. You can switch the response type to Facebook messenger to test that the cards are pulling through properly. If you are happy with the results, connect Dialogflow to Facebook messenger via the _Integrations _tab and you’re ready to go.

Further notes

It would be potentially beneficial to refactor our code and create a function for creating Facebook cards. Currently our getPost function is quite messy, and it would be better to separate those concerns
Sometimes people might provide multiple tags – Dialogflow has the ability to interpret entities in a list. Our code would need to be modified considerably but it should be do-able.
Remember to train your bot often – there is nothing worse than hitting a dead-end when chatting to a bot!
Integration into Chatbase is a must, especially if you are delivering large amounts of content via chat channels
Consider other chat channels – Slack is a good one and also offers cards
Enable caching so bot responses are faster.

What to learn next as a front-end developer

Vernon Joyce — Mon, 16 Oct 2017 15:20:36 +0000

As a frontend developer, it’s easy to get overwhelmed with the dizzying number of frameworks and libraries available. We work towards improving our skills, but knowing what to learn next is difficult; especially when you are just starting out. This article will help you make an informed decision about what to learn next as a front-end developer.

The great thing about development is that it’s always evolving, which gives developers a variety of study and career opportunities. An important thing to remember is that there is no right or wrong framework, library or language. Some front-end developers might recommend specific tools, but the framework or language you choose to work with should be one you love. You should choose something you enjoy, which compliments your workflow and which ultimately could land you your dream job.

Clients generally aren’t interested in how it’s built, as long as it works. You don’t buy a pair of jeans and think about how they were woven, you just wear them. There are however some exceptions to this rule. Working in a tech hub, your clients or employers might require you to use very specific frameworks.

With this in mind, let’s look at some tips and tricks on how you can improve skills and grow your career as a front-end dev.

Start by asking yourself where you want to be in five years time. Without a sense of direction there is no way you can accurately decide on a skill to learn. The type of framework or skill very much depends on the type of career you want to lead:

1. A dev-ops role:

In this case you should be learning about both front- and back-end technologies. Get an overview of the tech involved on a server level so you have the knowledge to effectively make technical decisions. This could also translate to any team leader role, being knowledgeable allows your team to look to you for guidance. This also very much depends on where you live as each industry in each County could vary. This sort of role requires you to be very knowledgeable, so a lot of reading and experience is required to get to the required level of expertise.

A big part of dev-ops also revolves around automating processes and ensuring your team has a well-rounded workflow. As a result this could be seen as a leadership roll and you will often be tasked with making difficult tech decisions.

Frameworks or technologies could include: PHP, Java or .net technologies, knowledge about system architecture, SQL or MySQL, AngularJS, React, Node.js, server technologies like Apache or IIS, UX tools like Adobe XD, unit testing tools like Qunit or Mocha, knowledge about how DNS works. It all depends on what interests you, but learn as much as you can.

2. Full-stack developer:

There is a lot of contention around what it means to be a full-stack developer. From experience, a full-stack developer would in his/her arsenal have: An understanding of design, a back-end language and a front-end framework (with architectural experience being beneficial).

Pick a back-end language like PHP, .NET or Node.js and get really good at it - it's the perfect skill to add to your front-end arsenal. For added efficiency, learn some design or UX theory. This will enable you to roll out a project by yourself from start to finish and make informed design and tech decisions about building good products.

Frameworks or technologies could include: PHP, .NET, Ruby, Java or Python for backend. For UX and UI,: Bootstrap, Adobe XD, Photoshop.

3. App developer:

This is without a doubt one of the faster growing industries in the world, whether you are building native or progressive web apps. There is a lot of opportunity in the app industry and many frameworks to choose from and this is especially true in developing countries.

Frameworks or technologies could include: Ionic, AngularJS, CSS and HTML with Adobe Phonegap, Apple’s Swift.

4. API developer:

With the advent of microservices there is a growing need for really good API developers. You would be responsible for building new APIs or maintaining existing ones. APIs often plug into other microservices; so you would be required to have a good understanding of how other APIs can be utilised and plugged into.

Frameworks or technologies could include: Node.js, .NET, C#, Postman

5. Be better in a specific role:

If you want to just be a better front-end developer, then make sure you know your basics very well. Simply knowing CSS and HTML isn’t always enough, you need to know it intimately. Then learn Javascript and only then move on to frameworks. Not many people are exceptionally good at doing front-end (especially when it comes to creating good user experiences with well-built user interfaces). The web isn't going anywhere soon so it's worth investing the time to become the best in your industry.

Although the front-end industry is often abuzz with frameworks like AngularJS, this does not necessarily mean that they have been fully adopted in your country. Many countries with young dev industries don't use React in production, as an example. This is especially true in South Africa where many large corporations still have flat or coded HTML and CSS sites applications. This works in your advantage as it means you do not necessarily have to rush learning a new framework. There is more than enough time to get to know a framework you love really well.

6. Enjoy what you do

The most important lesson we can take from this is to just enjoy yourself. If you have a passion for front-end development then you won’t have a problem learning something new. Just take your time, soak it in and remember that you don’t have to learn all the languages in existence in a single day.

8 tips for being a better developer

Vernon Joyce — Fri, 13 Oct 2017 08:36:37 +0000

Front-end development is ever-changing, and we often find ourselves needing to change with it. Whether it’s the next big framework or language, there will always to an extent be something new to learn. But how do you go about growing your career or learning new skills? How can you be the best developer you can be? Here are 8 tips for being a better developer:

1. Be honest with yourself and employers

There is an interesting movement happening in the dev industry, especially in South Africa. Many developers tend to add skills to their CV that they don’t necessarily have. Having only read an article on AngularJS does not give you the authority to add it as a skill. Remember that your employer will depend on you and will expect you to know what you are doing. Only add a skill if you are confident that you can run a project therein from start to finish, on time.

2. Tailor your CV

Tailor your CV for the type of work you want to do and not necessarily the type of work you think you should be doing. There are many front-end developers that know only CSS and HTML and lead very successful careers and it could potentially be a stepping stone into a better position. It’s about what you as a developer feel passionate about and where you see your career heading. If you know AngularJS but have no interest in building AngularJS projects; don’t feel ashamed to remove it from your CV. Chances are your prospective employer will take in interest in that skill and you might end up doing something completely different to what you applied for.

3. Pick a framework you like

Pick a framework or language you like and spend a lot of time getting really good at it. A business’ main goal is to make money; if you work efficiently you will get rewarded. This is not to say that you should only focus on a single framework, but it helps to be exceptional in your field of interest. In a lot of countries; like South Africa; frameworks like AngularJS or React.js are still very new. They will most likely only be fully utilised in businesses in a few years’ time (this of course is not to say that there aren’t businesses already using these frameworks). This means that there is more than enough time to learn a new framework and will ensure you are ready to start working therein once it reaches its peak. Do some market research to see what there is a big need for as this could ultimately help you make the right decision.

4. Learn how to work with clients and manage projects

A big requirement for most professionals in our industry is the ability to run a project and work with clients. Often in the development industries you might be building projects by yourself, so your employer will expect you to be self-sufficient and work closely with your clients. This also relates to our first point: you can’t effectively run a project if you don’t understand the technology you’ll be using. Learn proper email etiquette, how to write briefs and how to manage your clients’ expectations to ensure that their goals are realistic and you will set yourself up for a promotion into a senior role.

5. Pay attention to detail

Get really good at attention to detail. It’s important that you uphold a high standard of work. When you receive designs, make sure they are pixel perfect as this is what your client (and most importantly your designer) expects. Adhere to coding standards; whether it relates to code syntax, folder structures or managing code versioning with git. When moving into a senior developer role these are the skills that will separate you from a mid-weight and it will also improve your overall workflow.

6. Learn some design

Many developers start out as designers before they move into Web. Knowing how to design gives you an incredible edge over other developers in the industry as it enables you to be better at pixel perfect development and also enables you to make design decisions when it comes to prototyping. Many developers build products without considering UX and UI – this is simply because they don’t know any better. By learning a few simple design concepts you will be able to do rapid prototyping and do a lot more dev work without a designer looking over your shoulder.

7. Build templates

Learn how to work with templates from some of the big CMS systems if you are interested in building brochure websites or interactive experiences. WordPress and Drupal aren’t going anywhere anytime soon and you can make a killing off of selling templates. More and more this is becoming an essential skill; knowing how to build WordPress templates not only gives you the ability to build nearly any type of dynamic website but also teaches you a lot about languages like PHP.

8. Freelance

Do freelance work where and if you can. This will help you with all of the suggestions on this list by giving you a space where you can practice your skills. Doing freelance web development is rewarding and will push you into new avenues and will connect you to new people. The best part about this is that if you fail at a project it won’t cost you your job, so there is a lot of room to grow and be playful.

Where to next? Now that you know about being a good developer, check out our recommendations for What to learn next as a front-end developer.