A short while ago I saw this great video on Youtube about web page performance on mobile browsers by Colt McAnlis, a developer advocate at Google which was held at HTML5 DevConf in San Francisco.
For those of you who don’t have time to watch the entire talk, I would like to briefly summarize what has been said, as I consider some of the points very useful in order to improve page load times on smartphones.
First of all, we can roughly split up the topic into three pillars of web performance:
- Network performance
- Render performance
- Compute performance
In the network performance part, Colt talks about the following three aspects:
- Why is mobile slower: As a matter of fact, cell phones are just a HAM radio operator and only enabling a network connection can take up to 1-2 seconds, which compared to the 3s tolerance before 50% of users abandon your page leaves you with 1s for your page to load.
- The trouble with images: Many pages still download full-sized images on mobile devices and the compression is not optimal, we should start establishing new formats such as the web-p format.
- Your content is too raw-large: A lot of websites still serve their CSS and JS files uncompressed, although it is easy to set up compression and it saves the user a lot of bandwidth.
In the render performance part, he covers the following topics:
- What’s your render-weight? It’s actually quite important to have in mind the rendering mechanisms of browsers. Though being very advanced you should consider what happens in the background when using CSS features like border-radius or box-shadow. More about this topic can be found in his article on HTML5 Rocks
- The trouble with images #2: Apart from downloading massive image data, a browser also has to deal with decoding and resizing them. This can take a significant amount of time and should be tackled with responsive image techniques such as Picture Fill by Scott Jehl
- Reflows are the devil: This refers to scripts that redraw elements depending on specific page dimensions. As an example, Colt shows a script that redraws everything on the page piece by piece, which leads to the problem that with every loop the browser waits for the page height to be calculated before it goes into the next iteration. Something which leads to very poor performance.
In the compute performance part, Colt talks mainly about the following issue:
- Static memory javascript: Due to its dynamic nature, javascript allows us to define variables wherever and whenever we want. This leads to the problem that the garbage collecter, which takes care of freeing up memory in a predefined interval which we have no control over, causes little performance delays whenever it does its job. This can be during a mouse click, while scrolling or during an animation. In order to prevent this from happening, we should predefine ALL our variables beforehand by calculating the max footprint of our applications.
- This can be achieved with the help of Chome’s built-in developer tools which can be found in the profile tab and allow you to measure CPU as well as memory performance of your javascript code.
Last but not least, Colt has put together a checklist for the mobile web which summarizes the above-mentioned performance issues:
- Use advanced data-compression for image transfer
- Use proper xfer protocols for fast-as-possible speeds
- Batch network communication through the radio
- Reduce page render-weight
- Reduce image-resizs times by scaling down images for mobile
- Batch reads/writes to the DOM
- Move towards static-memory usage patterns
- Know your growth rate
- Know your max memory footprint
- Preallocate
Timeless web development best practices
In today’s web development world, we are constantly confronted with new technologies and innovative methods for solving problems more quickly and efficiently.
But instead of setting up just another post about the latest javascript or PHP frameworks, I wanted to take a step back and talk about some underlying principles of web development that in my opinion have proven to be useful and persistent over time, because they can be applied to most development cycles without depending on a specific technology or programming language.
What follows are some easy to understand concepts that you can implement in your medium-sized design agency or freelance processes to accomplish a few important things that probably all of us are aware of are almost always in danger:
- Quality won’t be as great as promised
- Deadlines can’t be met as scheduled
- Project is going to cost more than expected
Requirements engineering
People usually have different expectations about a system. Most of the time, misunderstandings occur when two (or more) people have different assumptions about how it functions.
Enter “Requirements engineering”. Having been an important field of software engeineering for a long time, this process helps us define proper assumptions and a more precise scope for our applications, so that things don’t get out of control during the development phase.
Defining use cases
One essential step of it is be to define all possible user scenarios of your application. Each of them represents a possible action that the user may want to take. This can easily be achieved by opening up a new excel sheet and writing down line per line what you want your users to get done.
In your concept, design and implementation phase, this list is going to back your user interface decisions and help you focus on how certain things are supposed to work – and how they do actually perform.
Most developers are familiar with the Unified Modeling language, so you might as well want to visualize these use cases in the corresponding diagram type.
Interviewing potential users
I think there is no better way to define the exact requirements of a system than actually talking about it with potential users. This can already happen at a very early stage of the analysis phase.
Since you already have a rough plan on how to put your ideas into practice and what your solution might look like, ask some people about their opinions and how this system could be designed to be more user-friendly.
In later iterations you might want to do some more profound research with the help of focus groups.
It’s mostly the non-experts and non-developers who give you the best insights because they don’t have to consciously fade out all the technical details but simply focus on what their experience should be like.
Inventing personas
As an alternative or even in combination with the interview method, you can define some imaginary characters of your potential target group.
Let’s say you have an application whose goal it is to simplify job searches. In this case one potential target group would be the job seekers, and on the other side the employer. Now you already have two potential personas.
Give them names: The job seeker is called Joe, the employer’s name is Robert. Now give them some characteristics: Joe is 24 years old, recently finished his architecture career and is eagerly looking for an internship. Robert on the other side is 36 years old, owns a gardening business and is looking for new employees that have 10 years experience in the sector.
Based on this you already have a very good picture of two interest groups that might be using your software. Now you can go ahead and confront those “imaginary” characters with your product. Try to do what they would be doing in their particular cases. I promise you will find a bunch of interesting issues that you were not aware of while planning your project.
The paper & pencil phase
What follows is usually the part of the project where you start to scribble, sketch, fantasize, test, create, discard, and just let your creativity flow.
While you should enjoy this process as much as possible because you are still allowed to do mistakes, it should also lead to some sound results that the rest of the development cycle can be based on.
The following may guide you in the right direction:
Specifying beforehand
If you have the time and resources, put together a collection of scribbles for each screen of your future application.
Based on these, you can define each screen’s user interface components and which functionality they represent as well as the states they can be in.
This document should exist before you actually start implementing anything. This may sound stupid and overly cautious but I have seen it happen that people develop something that they think needs to be there but has never been asked for.
Like this, you can be sure that all team members have seen and – more importantly – agreed upon what is going to be accomplished, preventing misunderstandings at a very early stage.
Quick prototyping
Consequently, the next step would be to outline the application’s interface and test some of the basic functionality with the help of rough user interface designs.
At this stage, you’ll want to show how things are looking on the screen, without going into too much detail, something which would be perfectly in line with the concept of Prototyping in the browser.
Instead of working on pixel-perfect Photoshop layouts which are usually not congruent with the end results, start shifting your mockups directly to where they are actually going to live and breathe. Maybe you even want to go down a different route and try to design your user interface with the help of style tiles.
This allows you to directly expose your design to each of the target devices and start testing right away.
Planning flexibly
While there is nothing worse than a project plan that you define once at the beginning of the project and never change, many people in business are still thinking that you can “anticipate” every possible problem and circumstance in the analysis phase of your project.
From my experience, it makes more sense to set up a rough application infrastructure and timeline at the beginning instead and let it evolve over time. That’s also one of the best advices I have been given once by one of my computer science professors at university: To let your Gantt charts, UML diagrams, and application infrastructure breathe, develop and emerge over time.
This allows you to stay flexible and react properly when new challenges occur. With every new issue you face, like a deliverable that is delayed or a technical problem that requires extra resources, go back to your initial plan, revise it, swap priorities, and in the worst case, start it all over again, but this time with the new insights that you have gained.
Agile implementation methods
The approach of rapid development cycles has become very popular during the last couple of years. Agile due to Wikipedia means “software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration”.
Let me pick three of its popular methods and describe them briefly as I think you can easily apply them without having to study the topic in its entirety.
Working iteratively
This ties in with the rapid prototyping method. Once you have shifted your layouts to the browser, get ready to incrementally fine-tune.
Iteration helps you to break up your big, seemingly monolithic project into smaller, more managable units. These units are small enough to be accomplished during day or week-long sprints, so that you can regularly present a new functionality to your project team.
These units can be split up among groups so that each of them can work on new features in parallel. With the support of unit tests, each feature can be tested and approved as an encapsulated module and then be integrated into the whole, something that is commonly achieved with continuous integration.
Delivering daily
This may sound odd, but it makes perfect sense to deliver new results on a daily basis, even though they may be small, seemingly insignificant improvements.
Not only does this approach contribute to the project team’s motivation and trust, but it also prevents you from hiding in your work and working on a new, heavy feature that eventually turns out to be useless or not in line with the requirements.
A project team usually appreciates it when you deliver regular, small results over time instead of promising a big release every week and not keeping up with expectations.
It also allows everyone to be part of the decision taking and get a deeper understanding of possible complications. The more transparent you are with your team, the better your relationship with it is going to be.
Don’t launch
This probably only works if you are not in some kind of client relationship, but are developing a startup project or are part of a team of like-minded fellows.
In order to not set the expectation bar incredibly high and avoid putting enormous stress on the development team (which in return can’t deliver good quality) just settle on releasing an acceptable version of your product as soon as you feel comfortable with it.
By agreeing on releasing something that is not perfect, you can already collect important user feedback that will help collect valuable user feedback and maybe prevent you from some decisions that you would have otherwise taken, such as a elaborating on a feature that turns out to be useless.
The inspiration for this idea came from the blogpost “Startup Lessons Learned” by Eric Ries.
Conclusion
I’m sure that you are already familiar with one or the other method I have mentioned. That’s great! It’s also important that we remind ourselves every now and then of the concepts and best practices people have invented throughout the history of computer science.
This summary is particularly meant as an inspiration to make use of the great possibilites we have at our disposal. Often times, we dive quickly into the design and development phase, since this is where things actually get created. I find it important however to also take a step back sometimes and look at the overall picture and if we are happy with the way we approach projects.
I hope you’ve enjoyed the article and I’m looking forward to your feedback, especially what kind of processes and methodologies you have established in order to deal with projects in the most effective way.
A Future Friendly Web
Here are the slides of a presentation I held at “Betabeers Valencia” on 25th April 2013 at Workether. (http://betabeers.com/event/betabeers-valencia-840/)
It’s about the changing technology landscape and covers paradigms how we can better prepare our websites for the future
I included much of the material that is listed on the website of the Future Friendly initiative: http://futurefriend.ly
Workether and Germans who are working in Spain
About two weeks ago the Valencian local newspaper published an article about the co-working space that I’m working at.
They’re briefly introducing what the idea of co-working is about, who the team behind Workether is and even did a short interview with me. (where I painfully realized how bad my German accent sounds…)
Enjoy.
How to cultivate your ideas
Usually, when having a good idea, we get excited about it instantly. I’m talking about the inspirational moment when the idea pops up in our mind, and we would like to start acting on it immediately, tell everybody about it and celebrate how great it is.
One week, or one month after however, the same idea is still only an idea, due to our oh so busy lives and its many responsibilities.
It is not that every single idea that we don’t act on is a lost opportunity. Luckily, many ideas come back regularly and stick in our minds, but acting on them is notoriously hard and requires not only overcoming the obstacle of actually starting to act, but in the long run a lot of discipline and will-power.
That’s why I wanted to put together – from my personal experience – a list of easy actions to help turn ideas into something tangible. I chose to use the verb “to cultivate”, as it implies the idea of consistency and care, something which is required to make something grow over a long period of time.
Keep a list or book of ideas
This method is very simple, so simple that it takes only a few seconds per day to apply.
Whenever an idea comes along, put it in your personal notebook, something that is nowadays integrated into most people’s mobile phone. Personally, I use Clear and Memonic to put down my thoughts into a specific list.
Only the act of writing it down already creates some sort of commitment in your mind to do something about it, and lets it evolve into more specific ideas and actions.
If you are able to establish a regular habit of writing down and elaborating on your ideas you will eventually end up with a detailed plan on how to put your ideas into practice.
Do just something
As I mentioned before, the fear of doing something about your objective can seem overwhelmingly painful.
Most of the time however, once we get into something and start exploring its complexity, the fear disappears and is replaced by clarity about the upcoming tasks and you realize that the fear was an illusion, something that your mind made up in order to not leave your comfort zone.
So go ahead, and start with the most simple, most basic possible action. This will mark the beginning of a path that you don’t know where it leads, but at least point you into a direction where you can go.
Create, but also discard
With the huge amount of ideas that we have written down and are eager to put into reality, we might at times feel a bit lost, because we want to do “too many things at the same time”.
Sometimes ideas are brillant, other times they were just valid in a very particular situation or context, but don’t have any longevity because the topic turned out to be too complicated, too heavy or too useless.
That’s why I suggest we should radically filter out ideas and relentlessly discard the ones that we are not 100% convinced of and make space for the most potential ones.
Set time slots
Ever had the feeling you never find the time to dedicate to your own stuff?
Very common, but if you think about it, not so difficult to resolve. Imagine why you are at work at 9 in the morning, or why you appear just in time for the match of your favorite soccer team.
First of all, because you care, second because you have consciously reserved time spans for these activities. So if you really care about your idea and value its importance, set aside some time during the week, sacrifice other (leisure) activities, and focus only on this particular thing during that period of time.
When you notice it’s worth it and you need more time, reserve 2 hours per week and incrementally invest more hours as the project evolves.
Steal, copy and imitate
Not having the resources at one’s fingertips seems to be one of the most common problems why people don’t start acting.
If that’s the case, I would propose you to look at an article about “The Basic Elements Of Creativity” (taken from brainpickings.com) whose conclusion is that copying is actually a part of every creative process.
A historic example of this approach is the following story I took from a book that I read a long time ago:
Orson Welles, director of the legendary movie “Citizen Kane” could not find any backers, but he did raise a small sum for casting.
He begged, borrowed and cajoled people into building sets and shooting full-blown screen tests which eventually formed a third of the film.
IT EXISTED.
Backers could see what they were getting. He got the money.
Embrace the unperfect
Though most of us desire good to perfect results from the beginning, things do usually not turn out to be that simple during the first attempts, but usually evolve over timing until becoming the masterpiece they deserve to be.
That’s why I like to use the following distinction:
“Continous improvement is better than delayed perfection”
It often happens that striving for a perfect result, you get stuck in a problem and don’t know how to move on. You feel demotivated and tense, because time is moving forward, but you don’t seem to be making any progress.
What if however you leave the problem aside, let it rest for a while, accept that it is temporarily unperfect, but still there and accessible for future improvements.
It happened a lot of times to me that when moving on with a different task, I undeliberately found the solution for a previous problem, because since I was making progress again, I opened my mind for new ideas, got inspired and creative again.
Talk and grow your ideas
Do you remember the last time when you talked with somebody about a topic that you were both very excited about ?
Sharing and exchanging ideas can be a very inspring process. So what if you carry your idea out into the world and tell everyone about it.
People are usually more open to giving positive, constructive feedback than we think they are. Most of the time, they even contribute to your initial concept with another idea. The idea starts to grow…
Even criticism (as long as it is constructive and not personal) can be a great thing. Other people and their opinions can help you look at a problem from different perspectives, thus making it easier to make an overall evaluation of your ideas’s feasability.
Review
With this input, I hope I have been able to give you some inspiration on how to start cultivating your ideas right away.
Keep in mind that there is no perfect moment to start acting, you just need to go out and create.
If the idea is too big, I found it helpful to set little milestones, or even baby steps in order to have small, but regular achievements over time. They will give you the right motivation to stay on target.
Good luck!
Boost your web development productivity with these rapid scaffolding tools
Recently, scaffolding tools in web development are becoming more and more popular. These tools can help you build your web application more quickly, providing you with shortcuts like an automated build process, image compresson, javascript minification and an integrated lightweight web server.
I’m gonna present four of these tools today, going a bit deeper into how they can help kick-start the development process of your project, which technologies they support and how they can assist you during the life cycle of your application.
Yeoman - Modern workflow for modern webapps
The first candidate comes from the likes of Paul Irish, Addy Osmany and other community fellows that work hard on making the web a better place.
Yeoman uses Grunt.js in the background to accomplish a majority of its tasks and during installation, it might prompt you to install some additional dependencies such as OptiPNG or PhantomJS, which Yeoman uses as little helpers to accomplish tasks while compiling.
After that, you can fire up a command line process that sets up a skeleton for your application. This can be based on commonly used web frameworks such as the popular HTML5 Boilerplate or Twitter Bootstrap for Compass. They’ll give you a proper starting point for setting up your work on well established community conventions regarding folder structure, cross-browser normalization and equip you with several pre-defined components.
Furthermore, Yeoman comes with so called generators that allow you to extend your projects’ scaffold by using predefined javascript application templates. These are available in several flavors, such as Backbone.js, Ember.js or Angular.js . They extend your application infrastructure by adding a basic programming scaffold and testing suites that can then be filled with your own sugar.
When you’re ready to deploy your app, the build command comes in very handy, as it takes care of all the heavy lifting that many of us are still doing manually: Image compression, compiling preprocessor code like Coffeescript or SASS as well as javascript and CSS minification.
Almost identically works the built-in server command,which will deploy your readily compiled application files and create a lightweight server process, allowing you to instantly open and test your application in the web browser. In the background, the process will keep on watching for changes, that means, if you change a CSS style or something in your HTML document, it will immediately get updated without you having to refresh the browser.
To sum it up, Yeoman is a great all-rounder to cover the essential scaffolding and automation techniques used by today’s web development community. Especially the quite extensive topic of generators (as seen in the documentation) allows for highly customized and tailormade application templates.
Middleman - Makes developing websites simple
The next tool comes from Thomas Reynolds, the Technical Lead at Instrument, a creative design agency from Portland, Oregon. It’s essentially a command-line tool for creating static websites, the main difference to Yeoman being that it’s based on Ruby.
In order to install Middleman, you have to install the middleman gem, which requires you to have RubyGems installed. Mac OS X ships with these by default.
You can create projects based on pre-defined project templates, which beside the popular HTML5 Boilerplate include a starter kit based on HAML/SCSS or SMACSS (Scalable and Modular Architecture for CSS) scaffold.
Similar to Yeoman, you can have a local web server fired up which reacts to code changes instantly.
An interesting feature of Middleman is that inside your templates you can use the built-in templating language ERb to take advantage of programming concepts such as if-statements, variables, loops and custom layouts. The latter for instance allows you to use different layouts for each view, based on a specific route that you define in your configuration file.
Let’s look into some more advanced features of Middleman:
Local data makes it possible to have the data of a page separated from its implementation. This only requires you to set up a separate data folder, where you put YAML files which define certain content variables. In the actual template code, you can use “placeholders” to access their values.
Rack middleware is a feature that provides a way to hook libraries and plugins into the system before the Middleman server processes them. For example, a tidy markup cleaner which indents and formats HTML code the right way or a validator that checks if your markup is in compliance with the W3C established rules.
Custom extensions are another method of hooking into the Middleman ecosystem, and need to be activated from your ruby configuration file. Supposing you’re familiar with the language, you can write your own methods that provide additional features and extensions for your application. An example would be a simple link helper for your view or a sitemap generator for building an XML representation of your site’s structure with every build.
Brunch - HTML5 application assembler
Brunch is the perfect tool for the sophisticated JS developer that wants to build single-page web applications based on advanced script languages/frameworks.
By default, Brunch comes with Chaplin, a Backbone.js based architecture written in Coffeescript. There are numerous alternative application templates which include different preprocessors and javascript frameworks.
The actual Brunch assembler functions the same way as the before-mentioned tools, providing a server and watch process which wraps all scripts and templates in common.js modules, thus protecting them from public access and facilitate code encapsulation. One nice feature is that when you have a desktop tool like growl installed, brunch will automatically let notifications pop up when build errors occur.
Accompanying the flexible nature and language independency of the framework you have an extensive plugin repository at your disposal. It includes compilers for script and style languages such as IcedCoffeeScript and Livescript, template engines like Handlebars, or Mustache, plus various minifiers and linters.
One feature that distinguishes brunch from its competitors is compilation speed. Unlike Grunt (which Yeoman is built on), it recognizes which parts of your application have changed and compiles things a little bit faster.
Luckily, for those who are completely undecided, the brunch guys were nice enough to provide a comprehensive compare table with other scaffolding tools that points out its advantages and inconveniences to others.
CodeKit - The Mac app for web developers
For those that are not so familiar with the command line, here comes a tool that is actually a desktop application and can be downloaded directly from their website. It’s important to mention however that it is Mac only.
CodeKit comes by default with CSS preprocessors SASS and Compass, allowing you to easily set up new projects of this kind in a matter of seconds by using the predefined folder structure. It also supports other preprocessors and frameworks such as Less, Stylus and Bless for CSS or Jade, Haml and Kit for HTML, the latter being Codekit’s very own templating solution.
In the preferences settings, you can change the parameters for each language, telling the program how it should render the output (regular, compressed), check the syntax (JSHint, JSLint), and where to put the resulting output. It’s like a user interface for your configuration file, a thing which in Yeoman (gruntfile.js) or Middleman (config.rb) has to be accomplished manually.
Once you’ve got your project up and running, it will be watching for changes and render preprocessor code to the configured folders. Whenever you update something in your file structure, CodeKit will notice it and process the according changes. It’s running subtly in the background and gives advice when necessary, e.g. when there’s a javascript error that doesn’t pass the JS Linter test.
In order to collaborate with your team, CodeKit can also export your project specific configuration file in order to easily pass it on to your teammates, so they don’t have to set up everything again manually.
Compared to the other candidates, CodeKit is not a free tool. After the free trial period of 10 days you’ll have to pay (at least) 25$ to continue using it.
Conclusion
As you can see, it’s almost impossible for us as modern web developers to ignore the tools that are created around our work in order to accomplish things in new and innovative ways.
The purists among us who have already established certain methods and guidelines are gonna say they’ll not achieve results any faster this way. I admit that this is usually not the case in the short-term, since you need to change your habits and get familiar with some new techniques.
Depending on the complexity of your project however, you might want to familiarize yourself with some preprocessors and frameworks and notice the difference coming slowly but surely. The learning curve is usually quite steep but after a few month, you might not want to miss out your newly integrated tools anymore.
Hope you enjoyed reading this post and gained some new insights that will help boost your producitiy in the long run.
There is a big difference between professional, constructive criticism and personal criticism. […] Personal criticism is an evil thing, it’s negative and it stops innovation, whereas professional, constructive criticism is a wonderful thing. […] Keep it professional, and then we’ll all be good.
Source: 5by5.tv
