How to Convert a Tumult Hype Website with a Menu to Microsoft Azure and Integrate it into the CMS?

1

Dear Tumult Hype team,

We are looking to seamlessly integrate a Tumult Hype website into Microsoft Azure without the need for extensive replication. This is because we intend to add various elements to the website, including feeds, a webshop, SEO optimization, and most importantly, a Content Management System (CMS).

Initially, our plan involved creating a Hype Mockup that needed to be replicated, with the animated headers being placed as HTML elements. Additionally, we were considering replicating the menu and overlaying it on the header, which exists within something akin to an i-frame.

However, the process of replication has proven to be labor-intensive and imprecise. Therefore, we are in search of a more elegant solution.

The website was designed in Tumult Hype and is fully responsive, with two states: mobile (portrait) and desktop (landscape). It features responsive text boxes that are linked on a symbol basis for both computer and mobile versions, ensuring that changes made in one version are reflected in the other. These text boxes contain formatted text that adjusts in size to fit the situation.

There is also a menu for desktop and one for the mobile version, both linked on a symbol basis. Furthermore, they are linked to the titles of the respective pages.

The content remains the same for both devices, with scaling applied to achieve the desired size. The underlying symbols are shared between both versions.

However, the challenge lies in integrating this website into Microsoft Azure. The current method involves importing the entire HTML page exported from Hype, resulting in a mix of HTML, JavaScript, and CSS that is challenging to separate.

Should I consider exporting components separately? For example, having a file with linked text boxes using unique IDs, another file for the menu, and a separate file for the header. This way, they could be combined into a single page within Azure. This page could serve as a template and the foundation for the CMS, with CSS connections established there, allowing subsequent pages to be created based on the newly developed CMS.

Alternatively, should I make preparations within Hype, such as coding, to facilitate a different integration approach? I would appreciate your guidance on this matter.

Kind regards,

Ellard Ottevanger

2

You can load dynamic data and assign it inside of Hype, using Hype Data Magic or Hype Reactive Content. Both solutions allow you to use external data sources.

Hype Data Magic

This mature tool is equipped with a live preview feature, focusing primarily on integrating data from JavaScript objects into your Tumult Hype layout. The live preview facilitates real-time adjustments, making it easier to bind data and fine-tune the layout.

Hype Reactive Content

This is the newer tool but goes beyond being a simple data layer. It enables the binding of functions or custom data to content fields within your Hype project. Features like data visibility, data content, and data effect offer a nuanced approach to dynamic data integration, allowing you great control over how data influences the project.

Both tools offer flexibility in using external data sources and bring additional modularity and interactivity.

On a side note, since SEO optimization is mentioned, it might be valuable to consider how Tumult Hype-rendered content interacts with search engines. Tumult Hype generates HTML5 content, which is generally SEO-friendly. However, due to the dynamic nature of the output (animated elements, JavaScript-controlled states, etc.), additional steps like creating a sitemap or using schema markup may be necessary to ensure that all content is easily discoverable and indexable.

As you addressed the Hype team, I’m sure they will also respond to this thread … just a few hints from a fellow user.

3

This is a big question, but maybe these questions can help guide you to an answer that works well for you:

  • How many pages is the website? If there are 20 pages and they follow the same design where only the page text changes, then you can likely reuse aspects of your design in Hype and lean on your CMS for content updates.
  • It sounds like you're happy with how your menu + pages adapt on multiple resolutions. If you then begin slicing up your single .hype document into multiple pieces, this introduces additional complexity into your project that seem like they can be avoided by retaining a monolithic .hype document export. The caveat being: if this webpage takes a long time to load just the generated .js file containing all your symbols and text across your project, then splitting it up into individual pieces may make sense.
  • We have definitely seen situations where Hype has been used as a mockup + playground for design, and then it becomes just as performant to use this Hype export as the production/deliverable file as it would be to recreate the design in traditional HTML/CSS. Making sure this site is updatable as well as performant for end users is important, so I recommend making sure you're taking advantage of a few performance tips and testing in your targeted browsers + devices.

I think the question for me is what does this website look like when you export straight out of Hype? How long does it take to load on an average internet speed your visitors will be accessing the site from? If you split up a Hype document into 4 pieces, this will actually load the whole site slower as more connections are required to download it all.

1 Like
4

Dear MaxZieb, Thank you for your quick response! You offer new insights that are certainly worth exploring. Since I do this with a team in India who does the Azure part and I share the Hype, this still requires some energy. Figuring out what needs to be done in which program - and therefore who - is now the challenge.

5

Dear Daniël/Tumult Team, Thank you for the quick response. It's not even 10 pages. This website is quite simple and serves as a test to see what we will do in which program. Breaking it up was an attempt to disconnect the JavaScript code. Now it's too intertwined. The intention is to create a work flow that produces increasingly sophisticated websites.

1 Like
6

Why not split the data from the view? Hence, having your Content Management System (CMS) totally independent of how things look on the front end. This way, tweaking the design or making updates on the back end wouldn't affect each other.

Speaking from experience and what I've seen in the tech space, adopting a REST or JSON-based approach when doing this could be super beneficial. Such a setup is not just flexible, but it's also pretty scalable. Imagine the project grows huge – this kind of architecture can handle that growth. Plus, data formatted in JSON is so lightweight and quick to work with, making the user experience smoother and be reused in new frontend or future views. And as a bonus, front-end developers can play around with the design without having to worry about messing up the back end.

2 Likes