Best practices/general workflow for Hype?


(Rich Leach) #1

Can anyone point me to a best practices guide for building Hype files? Stuff like building my own libraries, reusing animations, using scenes to group sections of the production, anything?

Thanks,

Rich


#2

Hi @richleach

There really aren’t any best practices when it comes to Hype. What I could suggest is that if you want to re-use any animations that you export them as symbols. That way you can import them into any project. Also, you can save any Hype file as a template. This is useful as a beginning point for any future projects. For example, I have a responsive template as a starting point for any responsive type layouts that I need. Most of my re-usable animations I have saved as symbols to import into any projects.


(Rich Leach) #3

Thank you DBear, exactly the kind of useful stuff I was looking for!

Rich


(drewbullen) #4

I have to disagree with this.

Here is an old list (dating back to Hype 2) but many practices are still relevant.

Hype 2 - Best Practices

Twenty best practices that help facilitate document development with Hype 2:

Comment your code extensively during development: It helps to formalize what you are attempting to do and helps you during revisions in the future. It also helps if you share your code with others. However, remove these comments for production use and thereby ensure the smallest file size for fastest downloads.
Use templates and symbols whenever possible: Develop template scenes for animations that use many copies of the same scene. Develop and test these templates extensively before replicating them. Enormous amounts of time can be saved with a good template. Conversely, enormous amounts of time can be lost in making the same small change to 20 or 30 consecutive scenes.
Use guides extensively: Horizontal and vertical guides should be used extensively to shape your scenes and help align individual elements. These guides can be used to to delineate clear borders around each scene together with horizontal and vertical centers. it is good practice to develop a layout guide for each animation that clearly outlines the horizontal and vertical centers together with an element free border. Once a set of guides is placed on a scene they should be left there to facilitate future edits. They don’t transfer into production code so there is no reason to turn them off. Unfortunately, Hype doesn’t let you copy and paste guides between scenes.
Conceal a version number and date stamp in each animation: This is a particularly useful technique to tracking bugs and trouble shooting problems that develop over time. It is particularly useful in code bases containing many different versions of the same content. Of course, these items are most useful in development and probably should be removed from production code.
Include a “no script” code block in the document head: This code block (and associated message) checks to see whether Javascript is present and enabled on any computer running your document. Most computers have Javascript on by default but some users disable it occasionally and it is good for your program to handle this possibility gracefully.
Develop (or use) keyboard shortcuts to speed development: Hype has many keyboard shortcuts which help facilitate editing tasks in its development environment. It is also possible to construct custom keyboard shortcuts via the system preferences dialog in OS X. Some common ones I use include shift-option-commend-E for Edit Element’s Inner HTML, shift-option-commend-H for Add Horizontal Guide and shift-option-commend-V for Add Vertical Guide.
Use native Hype elements where possible: Hype native elements should be used whenever possible. While it is possible to recreate, and in some cases elaborate, Hype’s native elements using HTML5 code or external libraries there are no guarantees how these elements will be rendered in different browsers and how they will behave with future versions of Hype.
Use descriptive and distinctive element & label names: Items added to a Hype canvas have simple names that reflect their type (e.g. button, text, rectangle etc.) are added to the elements panel. Once more than a couple of these elements are added to a canvas it is impossible to distinguish between them. By employing descriptive and distinctive names it is immediately obvious what label refers to each item. Otherwise when elements are grouped, it is wise to give the group a descriptive and distinctive name instead of “group”.
Use grouping and/or nesting to organize and manipulate logical collections of elements:
Lock down elements once editing is complete: Inadvertently moving or misaligning an unrelated element during development can drive you to distraction especially if you don’t notice until some time in the future. Locking down elements prevents this possibility.
Use an element’s innerHTML to add custom HTML5 code: HTML5 tags and inline styles inserted into an element’s innerHTML container can be used to expand the number of available elements and/or to customize their appearance.
Order elements to adjust their stacking order: Remember anything the requires user interaction must be on the top level and not obscured by other elements even if they are transparent or invisible. Similarly frames and borders should be kept at the lowest level in the hierarchy of elements.
Save Javascript functions you want to reuse outside of individual project files: Create a snippet library of commonly used Javascript functions outside of individual project files.
Include multiple audio and video formats for each resource used in a project: This is especially true if you fore see your document being deployed across all browsers.
Copy and paste custom elements rather than recreating them: This makes for more efficient code use. Especially, use “paste with code” when possible.
Make incremental backups during development: This helps recover from machine crashes, file losses and errant development paths. Also, store copies of all important resources (i.e. images, javascript code etc.) separately from individual project files.
Note all compatibility warnings during HTML5 export:
Test documents extensively on multiple platforms and browsers: This is especially true for platforms that account different viewport size and aspect ratios. Media queries can be used to … It is also helpful to gain an indication of download speeds. Sites that appear non responsive due to sluggish download speeds are bad for business. If download speeds are likely to be an issue make sure to turn on the loading indicator.
Elaborate the exported index.html file to include terms necessary for good SEO performance:
Develop with each document orientation in mind: Lock in to one aspect ratio (i.e. portrait or landscape) from the start of development or undertake parallel development paths for each orientation and build the capability to switch between the two possibilities in real time (much harder).


#5

Hi Rich!

The following focuses on nomenclature in large projects (i.e. lots of elements, graphics, images, etc.).

If You are creating a large project I would very carefully consider the nomenclature scheme You will use for these elements - in particular for element IDs - and have a consistent approach with this scheme even when it seems overkill. You never know when You might elect to reference additional elements than in your original plan - or decide to add more nearly-identical elements.

So an id for a red rectangle isn’t just “redRect” - even if You just have two - it is “redRect_01” & “redRect_02”.

Edit: Re-reading the above line several hours later… You can’t of course have two elements with the same ID: “redRect”; the idea here was to keep the naming logically systemic for easier JavaScript manipulation… using “01” & “02” etc. instead of “redRect”, “redRectCopy”, or other arbitrary naming scheme.

If I have more than one scene I include the Scene Name. So if my red rectangle is in a scene named “Evidence” the name now becomes “evidence_redRect_01”. Scene name comes first in the naming scheme so it is easy to visually scan your elements list in the Timeline… all elements in the scene “Evidence” are easy to spot. Ditto (and even more importantly) in the “Resources” panel where resources are alphabetized. All the “Evidence” elements are together.

Season to taste.

I am currently working on a project with over two thousand unique elements. An example from my ID names:
“RE_Evidence_04_Profiling_Fossils_Topic_5.png”

I won’t bore You with how this element ID name breaks out into components - but I can tell exactly where this component belongs in my project at a glance - and I can slice these names up in Javascript without any involved selectors, making it simple to create multipurpose JavaScripts.


(Rich Leach) #6

Thank you DBear, precisely what I was hoping for!


(Rich Leach) #7

Jim, I really like your naming convention rules, will certainly adopt them into my own workflow.

Thanks!


(Ken Heins) #8

Who would have thought I would own a printer again?

But I have found that when doing testing of responsive, (or any) files, I have found it very helpful to print out a screen shot and make notes of the changes that need to be made, AND write a checklist on the printed screen shot. Also note the date and time. And save them until at least the next group of edits supercede the old.

And a screen shot of the screen detailing the uploads to the server.

All I know is, that when I don’t do that, bad things happen and work has to be done over. It WILL happen. You think you are going to remember the necessary changes, but…


#9

Just want to say I’m really enjoying this thread and loving all the recommendations!


(drewbullen) #10

You are welcome, Bernard


#11

potato, potarto! :slight_smile: [quote=“drewbullen, post:4, topic:6659”]
Comment your code extensively during development:
[/quote]

Javascript specific … not really Hype specific. Goes without saying any code should be commented if you are so inclined.

mentioned!

never really use guides as snap guides are enough for me. But not to say they shouldn’t be used. :wink:

Rather than do this I would just version number a stable file the file and then copy and increment the version number. Having to remove these when ready for production can be tedious :slight_smile:

These days Javascript isn’t something that people turn off anymore. It’s almost becoming standard and now that flash has hopefully bit the big one then more so. However I accept that you could do this per a project by project basis. depending on who your audience will likely be.

Horses for courses as the many shortcuts that are in place seem sufficient enough. Maybe a few could be added in future versions or a simple way to add them. Before anyone chimes in … I know how to add them :wink:

Probably the only real best practise! I would add also use the API too when possible. hypeDocument instead of document for example.

Best practise number 2.

Would be nice to get this into Hype in some form or another. Ehh Hem!!! @jonathan :slight_smile:

And do what with them … ? :slight_smile:

Best practise number 3!


So, in conclusion. I retract my earlier statement that there “really aren’t best practises” when it comes to Hype. But, I would tailor your own practises to suit. I mean there are so many different types of projects and ways people use hype and not all necessarily need code. But common sense is a must and when something works … save it and make another version before you move on. :slight_smile: if it ain’t broke … stop and copy it before you actually do break it!!! :stuck_out_tongue_winking_eye: I leave you with this … Apple S means less stress!!

DBear out.

P.S only kidding. This isn’t an attack on suggestions, just stimulating friendly discussion. As in the UK … BT said it best with … “It’s good to talk!”

Happy Hyping.


#12

Hi to All!

In particular those new to HTML animation programs utilizing Symbols - old hands need read no further ;->

When I first started using Hype a few months ago my structural~design~scripting ethos did not have Symbols in the flow - I was not use to employing this valuable tool… it was more of an appendage. Since those salad days I have gotten Religion.

Now any of my design concepts goes through the Symbols sieve - can I use Symbols for this process?

Symbols are flexible, lightweight in practice & can replace otherwise intricate JavaScript solutions with built-in capabilities. Symbols are not a magic bullet but are worthy of careful study so You can recognize the opportunity to use them when it arises.

The following is an example of Symbols at work - an image database - from a project I’m working on: nailing two avians with one projectile, with just a bit of JavaScript to pluck the feathers; currently a working schematic for the final design~scripting.

/============================================

Objective: Create A Relational (Panorama) Object Movie - other than jQuery, no ancillary JavaScript libraries Thank You!

First Bird: A series of (paleoanthropic) skull images taken at precise degrees apart in rotation, when viewed in sequence have a 360 degree rotational experience…

Second Bird: we need to isolate each image for comparative relational analysis with other species’ skulls in the exact same rotational perspective.

The following schematic (“HypeSymbolObjMovie.jpg”) shows four rotational perspective images for each species, out of 16 images in total. Four species shown below - twelve species in the final production - each one represented by a Symbol. So, from a database perspective, if You think of each Symbol as a flat file, the aggregate of the Symbols has a relational matrix.

At each image~frame location using the up/down arrow keys on the keyboard, or up/down arrows on the screen (i.e. iPad) will show the different species at the same relational rotation. This is where JavaScript (jQuery) will be used. Basically: match the timeline in each Symbol - then show 'n hide with one line of code - “toggle();”.

I love dancing with Hype.


“HypeSymbolObjMovie.jpg” - working concept…