True story: once I developed a state of the art web UI using an hyped framework which yielded great smiles over my customers face. Until he realized that this framework is not discoverable by Google search. Is this strategic enough for you? This post is focused on the worst mistakes a frontend team can make. It stands out from other ‘best practices’ posts by emphasizing the critical and truly painful pitfalls. Other guidelines are targeted for professionals who can afford dealing with the nitty gritty (which is important by the way) while the following list is intended for those who don’t have the resources at the moment to cover the smaller details but still wish to escape major mistakes and benefit a maintainable system. If you’re a product manager, a software architect with basic Javascript knowledge or a software buyer – copy the URL and share with the development team. Or even include in the contract.
-
Develop using one of the top five popular frameworks
What exactly should I ask from my team: Don’t code the project from scratch rather use a reputable framework which is ranked among top 5 in www.javascripting.com. Ask ‘what framework you intended to use?’, if the answer is different than ‘Angular’ or ‘React’ or ‘Backbone’ or ‘Meteor’ or ‘Polymer’ then start fearing the consequences (last updated at July 2015).
Why is it critical: Popularity is the number one criteria when choosing a technology , it ensures that you marry a framework with vibrant eco-system that will always come to your help in a competitive price. Otherwise, should you choose a niche framework – very easily you might find yourself struggling to hire new team members (or replace vendor) due to the dull eco-system or forced to develop expensive components which exist for free in popular frameworks.
When can I deviate from this advice: If your product requirements are genuine (i.e. not a standard web UI) and your team has remarkable front-end design skills and you have the budget to support this off-road approach (using standard tools is always more budget friendly) – then opting for a unique architecture might be the right choice.
-
Follow your selected framework’s style guide
What exactly should I ask from my team: Each reputable framework (see best practice #1) has a well-recognized style guide that outlines the framework’s best practices. Ask your team to follow the guide and share which specific guidelines were not applied and why. For example, here you may find the style guide of a popular framework – AngularJS and here’s the style guide for another popular framework – React JS.
Why is it critical: The code quality sets how flexible, fast and maintainable your code is. Poor code means much longer time to implement new features with higher price tag. Following the industry best practices increases the chances of having a high quality code.
When can I deviate from this advice: Never.
-
Apply a component-based architecture
What exactly should I ask from my team: This is not a standard and easy to explain guideline, but it might save you from coding your architecture with old style patterns that lead to inflexible architecture. Ask your developers to base their architecture on loosely coupled, independent and reusable UI components so that each can be ported to another application only by copy-pasting its folder. Practically, each component must be stored in its own folder which has all the necessary artifacts to operate independently – a controller, view markup, CSS files, services/stores and any other resources. Within each page that comprises multiple UI widget, ensure to embed multiple components that interact using some broker (i.e. bus, pub-sub, a component that is responsible for dispatching events with messages). Avoid having a single controller in a page that mediates multiple UI widgets.
Why is it critical: Violating this design principles has great chances of leading to an non-scalable system – one that it’s harder to change and maintain.
When can I deviate from this advice: If your application is really small, for example when a typical page contains no more than a single UI widget.
-
Code with ES6 Javascript
What exactly should I ask from my team: To use the future code syntax right now and avoid re-writing the project 1 year from now – code with ES6 (or TypeSript or AtScript) syntax, use transpilers to output ES5 code.
Why is it critical: At the front-end and Javascript world the only constant is change – projects are being re-written every few years to support new standards while the change cost is significant. Luckily, it seems like we’re entering a convergence era where firm standards seem to arise – applying to these standards right now is likely to reduce significant future costs on refactoring the code.
When can I deviate from this advice: If your team constitutes junior developers – the setup and the learning costs of these new standards might not worth the value, mostly in smaller projects.
-
Apply mobile-first approach
What exactly should I ask from my team: If mobile devices are of interest to your product, ask your team to design the page first or separately for mobile while ensuring that the load and rendering time is satisfactory in mobile devices. It’s very common in web projects to design first for desktop computers but then adapting to mobile increases the cost or degrades the mobile experience.
Why is it critical: Defering the mobile experience and tech design usually yields to sub-optimal user experience and page load time which not only decreases the user adoption but also carries search engine penalties (i.e. Google lowers the ranking of site that doesn’t provide decent mobile experience)
When can I deviate from this advice: If the vast majority of your product traffic comes from desktop users – then designing a desktop UI with minimal mobile adaptation stands to reason.
-
Apply common code quality guidelines and tools
What exactly should I ask from my team: While there’s obviously no magic recipe for writing quality code, in the absence of a team lead who can track the code quality, at least let’s ask the coders to avoid common pitfalls that directly leads to system with major flaws. These are the most critical code mistakes that I personally believe ‘frontenders’ use to do: (1) Avoid two-way data binding – keep the components flow in one explicit direction, should the UI wish to update the UI controller with new information (a.k.a view controller) use events instead of a magical data binder (2) Never change the HTML with JQuery selectors (e.g #someElement.html(“<div> hello world</div>”) as this a complete violation of the rendering flow in all the popular frameworks (3) Use CSS frameworks (e.g. SASS and COMPASS) and never define how UI element look like more than once (4) Employ code quality checker tools at your build flow such as JSHINT and JSLINT
Why is it critical: An old customer of mine, world leader at the printing industry, struggled to develop a new product version due to poor code, it ended with enormous costs and finally they closed the doors.
When can I deviate from this advice: Only in case of relatively small products.
-
Ensure your selected framework is SEO friendly
What exactly should I ask from my team: Some of the frontend world’s most reputable and used framework can not be crawled by Google search engine! If being found by Google search is a requirement, ask your team to ensure that each view and data are rendered also by the server (or any other technique that is SEO friendly).
Why is it critical: Does it really deserve an explanation? 🙂
When can I deviate from this advice: Ignore this guideline when developing an information system with transactional data that should not be crawled, for example: CRM, Todo app, etc
-
Define the initial view rendering load time
What exactly should I ask from my team: It’s very common to find frontend teams doing well-designed and fancy Javascript programming that ends with beautiful UI, which unfortunately lets the user wait for more than 10 seconds until the page loads… At our scattered times, when a product might get the user’s attention for few seconds fast loading is more than critical. So what exactly should you instruct and ask from the team? is it about the page size, the server latency or the page resources load time? Google search engine for example measure the time to first byte (how fast does the server response with the first pieces of content) and ‘punishes’ slows site, however this metric is misleading since it doesn’t measure how fast the UX is – in other words, how fast can the user start interacting with the UI. Consequently, my suggestion here is to define how fast it takes for the page to fully render. A common pattern is to start with partial view that has enough juice for decent UX and defer less critical components (e.g. Google analytics measurement, side widgets, ads, etc) to later time. There are many development techniques to achieve this goal (e.g. compression, minifaction, server rendering, caching, etc)
Why is it critical: Your prospect now waits for an elevator, she gets a link to your site as she waits, who will come first – the elevator or your amazing landing view?
When can I deviate from this advice: In a case you’re a product manager at Apple. Your customers will never leave 🙂
-
Avoid being sued for plagiarism or licensing violation
What exactly should I ask from my team: Engineers are taught to increase code re-use, only more than few case ends at a law court. It’s highly popular among web developer to use 3rd party components, some belong to companies who offer them for free under certain conditions(!) other appear at blog posts of engineer who work for companies with trade marks and IP protection – uncareful code reuse can lead to expensive legal expenses. Ask your team to notify and consult before any use of 3rd party components.
Why is it critical: Forgetting to pay for 1000$ component can cost much more than your entire R&D budget.
When can I deviate from this advice: Never.
-
Make the UI accessible to increase your target market and avoid regulation penalties
What exactly should I ask from my team: At the country where I live, avoiding to make a website accessible for people with disabilities is illegal and can lead to penalties. Not to mention our moral obligation in supporting disabled people. The things is, designing an accessible site beforehand demands almost no additional cost but making a site accessible at later stage might be pretty expensive – this is a good reason to ask your developer to conform to typical accessibility rules and specifically ensure that they satisfy the local accessibility laws.
Why is it critical: A loss of market share + unnecessary costs
When can I deviate from this advice: Never
Final words
Goes without saying, we’ve covered here on the tip of the iceberg. Developing highly flexible and snappy web UI requires professionals – having a consultant/architect/team lead is always benefitcal. However, if you have to hit the road fast without a frontend expert – asking the team to follow this list is far better than avoiding any best practices discussion.
-
Amna Sheikh