I used Hype 2.5 to build 3 webpages and I found myself implementing a reverse data lookup in every case. The normal SEO behavior of Hype is to export the text you use to the surrounding HTML document so it can be found by a search engine. I was really wondering why this feature only dumps the data instead of using the webpage as it’s actual data repository. So I implemented a function the reads a div by ID and grabs the content to replace the content of a DIV inside my project. The downside is that I don’t have the contet visible until publishing it and viewing it embeded in my preped HTML page.
Please implement a feature to store the content of a HTML widget directly in the page. Bi-Directonal edits would be possible (from Hype but also from the source-HTML)
Thanks for this feature request. We’d like to be able to do this at some level; though it isn’t quite as easy as doing a straight dump (there would be technical issues with running scripts potentially multiple times and such). Definitely on our radar to improve that way tags with semantic values to search engines can be exposed.
I am currently doing this by running a function that grabs an ID (example:headline_productsection) and locates a similar ID in HYPE and replaces the content on init …
After running some test from Google, my client now forbids me from using HYPE because Google doesn’t like the way you’re “including text for search engines”. Believe me, I’d love it if Google wasn’t going all “1984 Big Brother” on the development community, but they are. So until you guys deal with Google’s demands, I’m sadly out of luck.
Any chance Tumult could contact them as a company and find a “Google-Blessed” solution for this issue? I love HYPE. But I can’t use it anymore.
As hype is rendered on the fly through JavaScript and builds it‘s HTML after page load in the client it’s up to you to add the data into the DOM while rendering the page. The solution to look up the data from the DOM and use it in Hype solves the problem for me.
Building a complete page in Hype is not ideal for SEO. Specially if Hype just dumps it’s content without some good structure to it.
yes, same problem here. i built several websites completely in hype, but failed in googles search engine.
there´re some tricks, placing text outside of stage, but this doesn´t really work. i also edit the header manually.
but afterall the SEO-tests accomplished a maximum of 67%. this is bad for clients. they want to see a result near to 100%. also the speed of loading the index-page is important for google. slow loading sites fall out of ranking. if i have several scenes, hype gets a little bit sluggish.
so - question: is it possible to load first scene very fast and the rest in background?
I suggest you try blocsapp in conjunction with hype. With blocapp, you can easily define and implement seo descriptions. I think hypes greatest strength and focus is creating animated content for websites prototypes, ads, but not replace a web design app.
The problem is not SEO as this can be solved in not using Hype as a full webpage solution or implementing hidden content DIV’s with good structure outside tof Hype. Using Hype as “widgets” inside a CMS or a app like Blocsapp has the problem of multiple instances of the runtime if you don’t do an advanced export. Also a more narrow problem is …the moment you implement some dynamic (re)loading that reinitialises Hype instances you start accumulating “garbage” (memory and code). This is a much more pressing issue then native SEO in my opinion as it disqualifies Hype for React or Vue projects and also I ran into this when developing an extension for Twine using Hype.
Hope to see the next Hype punctual on the new AppStore as suggested in the last keynote. That should be priority number one. So feature stop and roll out ahead
Cheers from Summer-Max (I’ll be returning more often in autumn)
Agreed! Well, the average non developer would not care if multiple instances are running so long as the experience is not limited. On the flip side, you are 100% right it is a detriment to see multiple instances of the load x amount of times. Perhaps @Jonathan can address this sooner than later.
Well it sums up. If you do the regular export the runtime is in each Ressource folder and the URI is different for each so caching most likely won’t be helping. This adds additional loading time and page weight. As page weight is also a new factor in SEO it might even concern “regular” user/Webdesigner/SEO people.
Another thing: if you recommend putting data into the body currently Hype doesn’t allow to modify or add custom HTML to body. So developing a Hype project that loads the data from external Divs (discoverable by search engines) can’t be developed that easily with the regular preview. One needs to do a export into a folder and keep a separat html that doesn’t get overwritten.
To fix this there is the option to add html from the head to the body (using jquery) on preview so Hype can find external data divs. Also I evaluated a exporter script that added a new field to the hype development environment and put that raw into the body on preview.
Can you give me an example, if say I have three animated hype blocs within one page to be loaded in regards to just one runtime to be loaded once per three div blocs?
