![]() WordPress and Drupal both have modules and plugins to enable a RESTful API, which I’ve found to be the most straightforward way to provide data in a headless architecture. The good news is that your preferred CMS likely already has what you need. Maybe you’re building a native iOS or Android application, but you need a familiar, yet robust, way to provide data for it. Or perhaps you’re not building a website at all. Perhaps you want cleaner separation of front-end and content-management tasks-it can be easier to staff multiple projects when the responsibility for building a site doesn’t require everyone to know both the front-end rendering layer in addition to the backend of the CMS. Maybe you want to have control over the front-end markup and animation in a way that stretches past what your CMS’s theming layer can support. So let’s say that you’ve got some very good reasons to go headless. We were also able to let our team members focus on what they did best: with the James Ensor touchscreen, our CMS developers were able to take care of the data management problem while our Cinder developers could focus on the touchscreen application. The other important outcome was that we could let each piece of the project do what it does best-by letting the CMS simply manage content, we could use better tools for rendering the presentation layer. We didn’t dive into headless CMSes because it was trendy, we did it because we needed to solve specific problems (in the first case an aesthetic/creative one, and in the second a data-management one). Why do I tell these stories? The key lesson for us was that a headless CMS helped solve a problem. We now use them with JavaScript applications, iOS/Android applications, and touchscreens. ![]() ![]() Once we finished this first headless CMS, the rest came along quickly. This had a profound impact, bridging two sides of our agency’s practice that had previously operated in fairly separate spheres. We were able to quickly build the CMS in WordPress, giving content authors a familiar interface, as well as reducing potential data errors. Again, JSON was the glue-we had done some research into serving up JSON from WordPress, and once we found a JSON parsing library for C++/Cinder the two big pieces came together. Since we have a lot of experience with CMSes for websites, the challenge was how to connect a CMS to a touchscreen application. The second project wasn’t a website-it was a Cinder (C++) touchscreen application for the Art Institute of Chicago that helps visitors learn more about James Ensor’s multi-piece drawing, “The Temptation of Saint Anthony.” Prior to this project, we had completed another touchscreen project with the content managed via XML, and we felt that we (and our clients) could benefit from a CMS instead of hand-editing XML files. ![]() The client got a familiar CMS to work with, but also a very tightly-orchestrated front-end layer that captured their creative vision for the project. There are a few themes that do this, but after some testing and much research we decided to use the JSON API plugin. We eventually settled on AngularJS to support those transitions, so the challenge was how to merge AngularJS with WordPress, the CMS we were using. We wanted to create as seamless an experience as possible, which meant experimenting with different animated transitions between sections on the site. The first was a website for Haruki Murakami. We were curious about it and could see the potential benefits, but we only ended up doing it when it solved specific problems we faced on two very different projects. Brief books for people who make websites.Īt Bluecadet, we didn’t set out to do headless CMS development for its own sake.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |