Provide a Code View for Advanced HTML + CSS + JavaScripting

[jax]

Currently, Hippo Animator produces advanced and amazing interactive content as a HTML file and it is really lightweight etc. but there are issues :

1.  The output html file is messy and very difficult to edit as it contains absolutely NO formatting.

2.  The only quick way to get your hippo content into an existing website is via iFrames which are not an ideal approach to constructing the navigational elements of any website for several reasons.

3.  Creating larger projects that involve CSS for styling to handle responsive elements is pretty much impossible as Hippo relies on JavaScript to do this task in general.

4.  Exported HTML has all CSS and Javascript code inline so the advantages of external files are not possible to utilize.

---

So that's a quick outline of the current problem and this is a suggestion on how it can be dramatically improved :

1.  Add the option to specify and create individual JavaScript, CSS and HTML files when you choose to export a Scene as HTML.

2.  Have some basic Auto-Formatting applied to exported code so it has a chance at being edited by a 3rd party later on using a basic TXT editor etc. if need be.

3.  Introduce a new view to Hippo called "Code View"

---

What is Code View?

Code View provides the user with a view that displays the code in separate panels for the current scene.

An example of this would be liveweave.com/

As you can see there is a preview window and then a window dedicated to HTML, CSS and JS.  By maintaining all the code in these 3 individual panels it will enable users to create entire websites using well formatted, clean code that can be used professionally by 3rd parties later on to make modifications etc.

The inclusion of the timeline bar would be helpful as well as this could allow for code highlighting or similar and would make it easier to follow where in the code views the currently displayed frame of contents are being handled etc.

It also means that no external website software would be required and that your pages can directly take advantage of all the existing features offered by Hippo Animator directly.

---

Adobe Edge tried to approach this problem by loading your "dreamweaver" or similar completed HTML Page in and then let you apply advanced animations etc to specific elements inside the page. The result was a disaster and the output code was still a bunch of **** that no human could ever attempt to make swift modifications to. It also produced files that are around 1000% (10x) larger than those produced by Hippo Animator. Did I mention it has dependencies on proprietary file formats as well?

What we can learn from this?

Building a website first in an external application and then trying to animate aspects of it produces a poor result.

Building animated aspects of a website and then including them in your completed project via a 3rd party program like Dreamweaver or Expression Web 4 will also produce poor results if the code is all inline and unformatted.

---

BENIFITS  OF  CODE VIEW

1.  The Code for your website is being constructed and formatted using web standards every step of the way.

2.  Instead of trying to introduce advanced interactivity to a website using existing elements or injecting them into an existing website via iframes, the content would be developed at the same time as the website is being created providing a more fluid and clear workflow.

3.  Hippo Animator would find new uses in training courses as it would become a powerful tool for learning advanced CSS, JS and HTML5

4.  Hippo Animator would become a stand-alone application where you can either create amazing animated content that can easily be included in an existing website or produce your entire website inside of the program using the combination of WYSIWYG and traditional Code.

5.  Hippo Animator would be able to easily import an existing webpage so you could edit it just like you can in other Web Editors such as Liveweave, Dreamweaver, Expression Web 4 etc..



Further expansions to this could allow for handling multiple "Scenes" as multiple webpages in tabs etc or other methods of working with multiple Scenes in this new context.

[Hippani]

Hi jax, we're looking into stuff like this, but possibly not in the way you think. For example, the export HTML is not designed for editing 'on purpose'. The exported code isn't like traditional html, it's js that generates HTML depending on the browser. It's not like simple <h2>title</h2><p>test</p> code that you can just style easily.

iframes are an unfortunate requirement due to conflict and doctypes. e.g. in IE8 an iframe is used to force the VML doctype. If somebody knows a better way to solve this problem, we're all ears.

Maybe you need to think of this in a different way. Have you ever used bootstrap css? You wouldn't try to edit bootstrap, it's all compressed and closed to be as small as possible, like hippo is. Instead, you can extend it. What we're looking into is a way to have a hippo engine file (which is meant to be compressed and closed), and then an option to have external js and external css. Currently, adding global styles is very difficult. It would also be nice to have shared js files.

[jax]

Hey Gordon,
Well there are a few things to consider which you mention that I previously hadn't so it's great to ponder on them.

A question which may better help me to grasp the discourse of Hippo Animators' development is :

I understand that the currently exported code works as you described and I realise this is likely why the file size of Hippo Exports is so superior to competitors.


If I am understanding the process described correctly, wouldn't it also be possible to have the proposed Code View as an Optional alternative workflow for a less optimised file size that provided developers with the above listed benefits?


I think the biggest issue would be that Hippo Animator is currently coded to work more like WYSIWYG Web Builder than an application that works directly with HTML5, CSS/3 & JS. It produces a result with another code platform and then converts all this over to html on export as you mentioned. To handle importing HTML pages and their external CSS / Javascript files and then directly work on them from that point inside Hippo would probably require a complete re-haul which is unlikely to happen.


My main hesitation for considering Hippo Animator when I begin a new project currently is that I know anything I create using it can't be passed off to other web developers who are not using this software because they will want to make alterations to the way the end product functions over time and I can't expect clients to be forced into a dependence on using my services to make these adjustments each time for many reasons including on-going costs, time constraints and delays to mention a few.

Well formatted code with clear commenting and linked external css/js are fairly standard when it comes to dealing with 3rd party web developers as a sub-contractor, so whilst Hippo has the ability to generate amazing content quickly vs alternatives.. the inability to provide that level of professional quality to the customer reduces my uses for the software to a private/in-house development scenario exclusively.



Regarding the VML doctype I located this : support.microsoft.com/en-us/kb/932175 which seems to suggest that the issues with displaying VML Elements can be resolved by those lines of code provided, which appear to force it to display as Inline-Block vs a dependence on iframes. It's not a big difference as both are displaying the content inline but it does at least enable content to have the possibility of being separated out more into a format that can easily be introduced into an existing websites' HTML/CSS etc.



I've never used Bootstrap CSS but a quick look into what it is leaves the general impression that it has a similar functional purpose to using jQuery. I suppose comparing Hippo to jQuery quickly identifies the intended usage of Hippo Animator and explains why it will likely not become anything more than a viable option for closed projects where components developed using Hippo are never going to be altered by a 3rd party.

This makes using it for sub-contract work to larger developers out of the question. It means that trying to use this software to provide clients that expect a certain level of clarity in file structure for future expansion by other developers.. another closed avenue of usage.

The biggest distinction between something like jQuery and Hippo would be that jQuery is not reliant on a specific software to make modifications to how it is used and the queries are able to be included inside a clear and defined set of documents (html, css, js). Hippo will require access to the original Hani file and a copy of the Hippo Software to make adjustments to how the finished product works since all that code is "compressed".



I can't help but feel a little sad and confused that my faith and hopes of what Hippo represented may not be true. I always believed that Hippo Animator was the most viable pathway towards an advanced HTML5, JS, CSS editor that could be included and perhaps eventually replace all other applications in that front of the development pipeline by taking advantage of the superior interface and tools.


I guess from a business perspective I can see that having Hippo evoke a dependence on the software for future modifications would help encourage sales of the product since all involved parties working on a product would need to own Hippo Animator as a prerequisite to including exported content from it in a project.

The downside is that developers who prefer working in more mainstream applications will often refuse to adopt to suit sub-contractors. They will instead show bias towards competitors who can provide them with the same services using a format that can easily be extended upon with any capable html/css/js editing suite.



I'm fairly sure there is nothing Hippo Animator can achieve that you can't also achieve with a LOT of elbow grease and a standard HTML, CSS, JS editor if you know how to code well. It would just take more time to complete and would consume more storage space as an exported final product. The benefit of course is that it would be ideal for usage in all fields of website development at a professional level.

If only Hippo could find a way to take advantage of the existing tool-sets and provide that same level of access to clear formatted files you would result in by coding the project using a heavily textual and primitive interface.



Maybe I'm seeing this all wrong and my perspective of what Hippo really is .. is not accurate (I really hope this is the case). Please I genuinely want to be told that my observations are incorrect and that Hippo does want to become the tool I believe it has the potential to be.

Nothing else out there has the same potential because they have taken too many steps down those dead end roads and are being developed by corporate types who are not interested in being pioneers of the future for web development but rather care only for the bottom line profit margins. They don't understand the meaning of customer service and lack vision for innovative ways that advanced interactive content can be introduced into websites and mobile applications.

[Hippani]

We use that vml trick too, vml was just an example, there are lots of different browsers and sometimes you have to create a new page to make things work. The problem isn't with the hippo animation, it's more often the doc type of the page hosting it.

I understand your frustration. This is software that doesn't quite do what you want. It's the exact same problem as Adobe Flash. If you want to edit flash you have to buy the software. One of the reasons the file size is small is that Hippo supports about 100+ functions (we expect this to rise a lot), jquery probably only has 30 functions. When you export hippo, only the functions you use are included in the export. Also, all the variable names are compressed so they don't conflict with any js you add. We also remove all white space. This makes the file very small. However, if a 3rd party starts trying to edit the file, it's very hard to understand it, it's quite easy to break it and most of the features are missing.

Our solution to this is somewhere in the middle, like we said, to be able to separate out some of the js and a css file, but leave a hippo engine closed. So at least you can edit some of the code after export. It's basically a compromise.

[jax]

Well the compromise is warmly welcomed and hopefully it provides just enough of a solution that this can be a viable medium for dealing with larger projects and sub-contracting situations.

I was a little tired when I wrote my previous reply and probably hadn't mentioned that the comparison between jQuery and Hippo was purely at a functional level and not meant to be looking at their complexity differences.

If I were to draw a distinction between Adobe Flash and Hippo, I would say that flash content remained 100% "closed" from production to export as a self contained file. Hippo currently does work this way too, though the file types it uses are a lot more "open" or at least have the potential to be open if their generation occurred with this as a primary objective.

At a development phase, both Flash and Hippo work the same way using a different language to generate the content which is then exported as flv or html etc. HTML is a preferred output as, like you said, iframes aren't the worst thing for a web crawler now days.

I'm looking forward to seeing how the js/css solution goes. Hopefully it provides enough capacity for compatibility purposes as per previously discussed in this thread.


Will there be the ability to select an option like (remove white space in exported html) or (maintain white space and formatting in html export) in a future release of Hippo Animator?



EDIT

Regarding iframes I located the following :

blog.boostability.com/the-affect-of-iframes-on-seo/


"SO, HOW DO IFRAMES AFFECT MY SITE’S RANKING?

Since search engines consider the content in iFrames to belong to another website, the best you can hope for is no effect. iFrames tend to neither help nor hurt your search engine ranking.

It’s best to refrain from using iFrames on main pages that you want to rank highly in search engine results, because the content in those frames doesn’t help your SEO. Instead, fill high-priority pages with useful, unique content and save iFrames for other pages."



So from this recent March 2015 article it would appear that the use of iFrames for a website menu is a BAD idea. Actually from reading that, the use of iFrames for any critical content relevant to promoting the primary objectives of a webpage are not good practices.
 Even if you are indexing this content via robots.txt the crawler will see your website as a single webpage even if it is really several pages of content according to : www.sociallyvisual.com/blog/seo-indexability-accessibility/

Advertisement banners would seem to be the only really good use for iFrames where your SEO won't take a hit for the team. It's not that using them will lower it.. but more NOT using them could potentially increase your SEO ranking.

[Hippani]

From what I've read, iframes get parsed by most robots, but the iframe content is in no way connected to the parent page. We'd like to not use iframes but there doesn't seem to be a way to do what we do without them.

Currently being considered is an option to split the exported HTML. There is always going to be a closed and compressed section, but the rest of it might well be opened up.

[jax]

That's my understanding of them too. robots are able to include the contents of an iFrame with the rest of the website. The way the pages I read discuss it, it seems that all content inside iFrames will be linked by crawlers to the main index page. I know there is an SEO analysis tool out there to find out with 100% certainty what happens and how the content inside iFrames is parsed by robots but in either case it does seem to be a necessary aspect of the pipeline Hippo Animator needs due to the closed, compressed sections of code it exports.

The more code that is opened up for manual alteration, the more uses that can be opened up for the software which is a win win for everyone

Thanks for taking the time to consider the proposed concept. Who knows, maybe some day in the future there will be a Hippo Studio Suite or something which is a 100% open content production suite as HTML5 and CSS3 become officially supported web standards and we see a dominant shift towards Windows 10 and other advanced operating systems which come with default browsers reducing backwards compatibility.

The need for things like iFrames etc will be reduced and we will see it become easier to combine a timeline interface with a legible code editing panels that can handle the concept of embedding timelines inside timelines etc and other complex functionality.

[Hippani]

Who knows indeed.

[Alex]

With a free fashion eCommerce website template ( www.templatemonster.com/category/fashion-website-templates/ ), you can now start an online business quickly.