OK, what’s the problem?
It’s no-brainer that reusable software is great. It’s fast to implement, it’s affordable, it doesn’t drain your efforts. And you can always ensure that you aren’t buying a pig in a poke. Once you decide to redesign a site, go ahead and pick the theme that conforms with your expectations.
Yet there’s a pitfall.
Let’s assume that you’re planning to redesign your e-commerce platform. You have a working back-end, and you’ve just purchased a state-of-the-art theme. You just need some customization to align the brand new design with your website features: add some sections, remove others, change colours, perform a few rearrangements. And if you can’t handle it yourself, it’s worthwhile hiring technicians who’ll take charge.
That’s the point when our management department may have tense negotiations with you. The problem here is whether it’s faster to implement and customize an existing theme or build an original one. It appears that customization may sometimes be less time efficient than delivering it from scratch. And many clients with a hard-wired belief: “ready is cheaper” may distrust our candid intention to deliver it faster.
Do you imply that buying a theme is always a bad choice?
No, far from always. But sometimes it’s reasonable to build the new one. In order to make it clear, we’ve summoned our full-stack developer Vitaliy. He works both with PHP based systems like Symfony, Kohana, Wordpress. And also, Vitaliy provides front-end development leveraging his skills of JS, HTML, Angular, and Bootstrap.
Yes, this guy over here
He helped us to consider and describe both options for a generic blog website such as one we’ve redesigned lately. Vitaliy has roughly estimated all the development stages. The numbers we’re showcasing are likely irrelevant for your particular website but they are quite enlightening in a comparison.
So, how long would it take to customize the theme I like?
It depends. Outcome numbers may dramatically vary regarding the needed features. So we’ll give them in ranges and pinpoint that we’re assuming some generic blog website.
First of all, a developer has to assess the logics within the theme. It simply requires developer tools available in any common browser. With these plain means of research, he flows through CSS styles and elements to understand how they actually work.
Researching theme logics
In some cases, a developer has to deal with a template processor which is merely a mediator between back-end and front-end logics. It formats an output as you operate an interface. There are numerous template processors: Twig, Smarty, Blade are among PHP based. Researching the syntax of that processor might take another hour of work.
Tweaking and researching the Twig syntax
Research: 3-5 hours.
And what about customization itself?
Customizing a theme requires an elaborate approach both to a front-end and back-end as it’s likely that you have to conduct a few changes in the initial code.
First, it takes HTML/CSS editing to align a presentation layer with the existing back-end side. And once you have some features in your theme that aren’t supported yet, the back-end logics have to be augmented as well. That’s a common problem. You can find lots of themes on marketplaces that look like they have various modules (such as a weather widget, PayPal, a cart, etc.) though these may be entirely non-operational.
A relatively big chunk of efforts can be cut if you have a native theme deliberately designed for a system you have. Such CMS solutions as Wordpress and Magento are accompanied with themes marketplaces. Products there are well tailored to CMS logics and can easily be implemented.
If you have a bare HTML theme it will take 6 to 8 hours to adapt back-end of CMS, framework, or pure code of a platform to make API (application programming interface) recognize your theme and make it operational. And also a developer has to rebuild sections or adjust their division, adapt sidebars, headers and footers, etc.
Development part: 16-44 hours.
What if my theme isn’t mobile friendly? How long would it take to enable responsiveness?
It’s definitely a bad scenario if you fall in love with a non-responsive theme. Really, go find another one.
The most effective as well as straightforward way to turn a theme responsive is to use Twitter Bootstrap. This one is a front-end framework widely recognized for its convenience in building responsive web design across different platforms. A developer would have to rearrange sections for various screen resolutions, remove deprecated classes, and change behaviours of blocks in compliance with Bootstrap principles. It will also take some CSS editing to remove and add properties of classes.
This gif showcases the way properties of classes change as we shrink or stretch a viewport. Note that the image section disappears as the resolution turns mobile. It sometimes is a reasonable approach to move or merely hide elements as they grow unfunctional on smartphone screens.
Enabling responsiveness: 8-32 hours.
Almost. We need to spend some time testing things we’ve got. For minor or absent back-end changes exploratory or ad hoc testing would be ample. Substantial back end changes such as integration of various modules may require completing test cases. The latter will drain more time.
Testing: 4-8 hours.
What do we finally have? Keep in mind that we’re estimating time for a simple blog website.
Minimum time: 31 hours.
Maximum time: 89 hours.
Average: 60 hours.
What about development from scratch?
A lot of processes here overlap. That’s the image of a website Vitaliy has redesigned lately from scratch and which was taken as a reference for these estimations.
We’ve changed the logo and texts
Though unlike working over a pre-built theme, a developer has to deal with design in PSD files. Photoshop layers are divided according to sections and elements. To dramatically reduce the number of browser requests elements then are turned into sprites: a combination of all small images on the one sole yet the big one. It helps to display separate elements on a page according to the design with the means of CSS and optimize rendering.
This is how a sprite looks like
HTML elements are placed on a page within the Bootstrap grid with 12 columns. CSS properties also require some tweaking to add visual features such as shadows, gradients, rounded corners, etc.
A page within the Bootstrap grid
The integration between a back and front-end is pretty similar to applying a ready theme, yet it will take less time as original design is tailored to the existing back-end platform.
Development: 24-40 hours.
Sometimes mobile friendly websites need some specific behaviours. For instance, a number of elements and blocks have to be hidden or replaced on smartphone screens. In order to achieve that, you’ll need more time.
Mobile specifics: 4-8 hours.
And testing will remain the same.
Testing: 4-8 hours.
Minimum time: 32 hours.
Maximum time: 56 hours.
Average: 44 hours.
So, when should I choose customization and when development from scratch?
Let’s summarize as there are many variables that may tip the scales in favour of either option.
Opt for customization if:
- Your theme is highly consistent with the current back end features and won’t require many changes;
- Your theme is native to the platform. Bare HTML themes will require more time;
- Your theme is responsive;
- You don’t need to integrate third-party modules.
Respectively, if your situation doesn’t match those points above, you definitely should opt for an original design.
What should I also be aware of?
OK, there’re some things that stayed apart from our estimation though these should also be kept in mind.
Design. As we were estimating just development sides, you should consider a UI/UX part. It’s great if you can design your site in Photoshop yourself. Though delivering it from scratch, exploring UX specifics might be a relatively time-draining process. On the other hand, design may be unnecessary if you have a reference and customization is mostly subject to logics rather than design itself.
Incompatible modules. If you decide to install multiple pre-built modules, make sure that these are compatible. Otherwise, it will take dramatic refactoring of modules and a platform itself to reconcile these pieces of software. And once these modules have undergone substantial changes, they can’t be updated from a producer’s side.
Do you have something to add or disagree? Please, share in the comments section.
Make the right choices and stay tuned for updates.