Customer perspective to Web technology choices
•Download as PPTX, PDF•
2 likes•1,627 views
Custom front-ends vs. CMS-based implementation. What are the benefits of decoupled approach? What are the challenges with the decoupled approach?
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Customer perspective to Web technology choices
Similar to Customer perspective to Web technology choices (20)
More from Perttu Tolvanen
More from Perttu Tolvanen (18)
Recently uploaded
Recently uploaded (20)
Customer perspective to Web technology choices
- 1. 2015-12-07 Perttu Tolvanen (@perttutolvanen) / Web on the Edge Conference (Helsinki, Finland) Customer perspective to web technology choices Customfront-endsvs.CMS-basedimplementation
- 2. 2 Advisor in buying web and e-commerce projects technologyevaluations, platformselections,implementationpartnernegotiations
- 3. The past and the future of web technology? 3 Traditional static html publishing (+scripts & includes) Era of platforms (CMSs and e-commerce platforms) 2000- 2004- 2014- Real web applications (Javascript-powered user experiences)
- 4. Or just different options? 4 Traditional static html publishing (+scripts & includes) Platforms CMSs and e-commerce platforms 2000- 2004- 2014- Custom front-end Javascript-powered user experiences, even SPA This has many names: decoupled approach, headless (Drupal) and so on… Burning question right now: how to choose your approach if you have both website requirements and rich- application requirements? (and hybrid approaches are not very easy either…)
- 5. ”What is the best approach for me?” 5 Traditional static html publishing (+scripts & includes) Platforms CMSs and e-commerce platforms 2000- 2004- 2014- Custom front-end Javascript-powered user experiences, even SPA This has many names: decoupled approach, headless (Drupal) and so on… Decoupled approach is now coming back and many CMSs are wondering which direction to go… e.g. Drupal with headless vs. traditional, WordPress with REST API development… and so on.
- 6. How to choose between different approaches?
- 7. 2) Business owner requirements (management experience) How to choose between different approaches? 7 1) End-user requirements (target experience) 3) Technical flexibility (concept readiness) 4) Ownership requirements (lifecycle, support, cost) Agencies and developers tend to over-emphasize technical flexibility because they don’t want to disappoint customers by being inflexible. Customers tend to over- emphasize stability and proven-technologies. Those things are important if you are building a long-term solution, not when you are doing new business. These are often under- emphasized in technological decisions.
- 8. 8
- 9. 9
- 10. 10
- 11. 11
- 12. 12
- 13. Platforms vs. custom front-ends: 1) end user requirements 13 End-user requirements (target experience) • Time to first impression vs. rich experience after initial loading • Lenght of sessions: new visitors vs. engaged customers • Activities in sessions: browsing vs activities • Google ranking requirements (speed and performance, especially Javascript) ”When we drive traffic from campaigns to the site, it needs to load quickly and browsing must be fast.”
- 14. Platforms vs. custom front-ends: 2) business owner 14 • Content management requirements, e.g. media asset management, adding new content, preview capabilities • Digital marketing requirements, e.g. landing page management, changing media elements • Personalization requirements & future visions • Optimization requirements, e.g. SEO, A/B testing • How much internal marketing/content editing resources does the client’s web team have? Business owner requirements (management experience) ”How do I create campaigns and landing pages? How do I edit the front page?”
- 15. Platforms vs. custom front-ends: 2) business owner 15 ”How do I create campaigns and landing pages? How do I edit the front page?” For example Contentful is a great tool, but horrible for content editors (as any other API-CMS since you have no WYSIWYG, no preview, no scheduling).
- 16. Platforms vs. custom front-ends: 2) business owner 16 ”How do I create campaigns and landing pages? How do I edit the front page?” Business owners would prefer platforms (e.g. EPiServer or Sitecore) over any other choice if that would be only factor. Getting previews and rich editing experiences is truly powerful when you need to do constant optimization, content edits, landing pages and so on.
- 17. Platforms vs. custom front-ends: 3) technical flexibility 17 • Concept readiness / stability – do we know what we are doing? • Are we going to add a lot of features after the first version is live? • Are we going to build native mobile applications later? • Bottom line: The more you need technical flexibility (or fear that you need), the more it makes sense to build the front- end as custom implementation. ”We don’t know if this works, we might have to change the concept radically after 6 months or so.” 3) Technical flexibility (concept readiness)
- 18. Platforms vs. custom front-ends: 4) ownership • Stability of the chosen technology • Availability of developers • Cost of initial building and maintenance • Bottom line: Longer the lifecycle, the more this matters. 4) Ownership requirements (lifecycle, support, cost)
- 19. Guidelines for decision-making 1. Find out the client’s capabilities, requirements and wishes before choosing your approach. 2. What is most important? In end-user experience? In business owner expectations? How much technical flexibility is expected? How much budget has been reserved for the project? 3. Make sure the client understands the implications of choosing a decoupled architecture. API-CMSs, like Contentful, can make a lot of sense from architecture point of view, but they are not something that content editors like… 4. If you recommend an SPA-approach, especially explain what ’time to first impression’ means. SPA-approach can become very heavy (initial load, device performance). 5. And remember, platforms are not dead. They will come up with new hybrid/progressive approaches to help building more Javascript-driven experiences. Also clients expect to have increasing control over their websites and applications – especially when they start doing real business through the web service. 19
- 20. Perttu Tolvanen Web & CMS Expert, Partner Perttu Tolvanen is a CMS expert that helps clients choose partners and technologies for their Web, intranet and eCommerce projects. His daily work involves writing RFPs, analyzing proposals, meeting vendors and facilitating workshops. perttu.tolvanen@northpatrol.com +358 50 685199 @perttutolvanen http://www.perttutolvanen.com linkedin.com/in/perttutolvanen 20
- 21. www.northpatrol.com/blog 21 Buyer’s Guide to Web Projects
Editor's Notes
- My perspective is business applications and corporate websites – especially big corporations that have fairly large web estates. So Im not really talking about small campaign sites or small company websites, and talking about projects where buyers have typically several hundred thousand euros of budget – and they really want to do real business through the web.
- Currently developers have a lot of influence into what kind of technology choices customers end up using – because developers often have influence into what is the approach that is offered for clients. And currently for example we in North Patrol see very different technological approaches for the same projects. A customer can end up evaluating should they do the implementation using a platform, like EPiServer, Sitecore, Drupal or WordPress … or should they do a custom front-end implementation… possibly as a single-page-application or even as a static html with added javascript functionality. And then the CMS might be in a very small role, for example as backend system that is accessed through APIs, for example Contentful, Prismic and Drupal can be used like this. Also WordPress is getting the REST API soon, so we will probably see also those customer front-end implementations with WordPress also.
- Currently developers have a lot of influence into what kind of technology choices customers end up using – because developers often have influence into what is the approach that is offered for clients. And currently for example we in North Patrol see very different technological approaches for the same projects. A customer can end up evaluating should they do the implementation using a platform, like EPiServer, Sitecore, Drupal or WordPress … or should they do a custom front-end implementation… possibly as a single-page-application or even as a static html with added javascript functionality. And then the CMS might be in a very small role, for example as backend system that is accessed through APIs, for example Contentful, Prismic and Drupal can be used like this. Also WordPress is getting the REST API soon, so we will probably see also those customer front-end implementations with WordPress also.
- P
- P
- P
- P
- P
- P
- P
- From end-user point of view it doesn’t really matter whether you have a platform in place or you have a very custom front-end. For end-users its naturally all the same. However, end users do care about the speed and ease of use. Therefore the biggest question right now is that how heavily we are going to use Javascript? Are we building a fast website or are we building a rich application with Javascript? The biggest individual thing is the time to first impression question. Do we need high search engine rankings and instantly loading web pages when our users arrive to our website? If so, then we should probably use a less Javascript and produce our web pages as more or less static web pages. If however, we have loyal customers or very interested potential customers, we can use more Javascript and build a richer user experience even though it takes more time to load initially and might be harder to access with older phones and slower connections. For example with Kotinyt.fi it was decided that a hybrid approach would probably be ideal, because we have lot of fairly static web pages which need to be very fast to load even with bad connections and they need to rank high in Google. But we also have search functionality inside the site, that needs to be very dynamic and fast (filters). Also the check-out process was seen as a very critical area for the site, and that probably needed a more application-approach so that it would be very user-friendly. I think in the end this is a performance thing. If we want absolute page loading performance, then traditional model is typically better. But naturally when we build applications where the user interacts all the time, then going to a custom front-end typically makes more sense.
- In decoupled/headless model we often end up building our own layout tools, preview capabilities and a lot of other things that we can take for granted if we work with modern CMSs, like EPiServer, Drupal or WordPress. And we have to explain this to business owners, that they are NOT getting the same tools what they have had before – or they end up paying a lot of money for rebuilding those from scratch.
- In decoupled/headless model we often end up building our own layout tools, preview capabilities and a lot of other things that we can take for granted if we work with modern CMSs, like EPiServer, Drupal or WordPress. And we have to explain this to business owners, that they are NOT getting the same tools what they have had before – or they end up paying a lot of money for rebuilding those from scratch.
- In decoupled/headless model we often end up building our own layout tools, preview capabilities and a lot of other things that we can take for granted if we work with modern CMSs, like EPiServer, Drupal or WordPress. And we have to explain this to business owners, that they are NOT getting the same tools what they have had before – or they end up paying a lot of money for rebuilding those from scratch.
- The more we need technical flexibility, the more it makes sense to build the front-end as a custom implementation.
- The future will be more decoupled, and it makes sense sometimes to move the CMS to a more backend position and not build everything on top of CMS. That said, I still think that right now we are probably a bit too excited about the possibilities of single-page-applications. I don’t think the fully decoupled approach is the future. Instead we will get new ways to use platforms and their capabilities also in cases where we have built more Javascript-driven websites and applications.