I’d love to see Hype have components. After my experience writing extensions so far I’d like to be able to bundle stuff into a container… I’d consider that a component. Basically this would be a new type of symbol in the resource library. It would be much like an app on Mac OS meaning a “folder” in disguise. This wouldn’t mean actually revamping the resource panel by introducing some folder structure … rather it would be like a regular symbol with benefits.
For example double clicking it shows a filtered resource panel with the resources and functions that are associated with it. These in turn don’t show up in the regular resource panel view making that view cleaner and only project specific. There are some edge cases to consider like duplicating a component much like a symbol… that’s why I consider resources associated with a component. double clicking the duplicated component would reveal the same resources! Meaning there is probably some component identifier that can be set and is inherited by the associated resources. In the UI this could be set on the lower end of the resource panel and additionally be automatically set to the component on currently is inside (like view package contents on Mac OS).
Installing components would be like dropping a symbol on stage and updating it would be like copy and pasting it from another document or loading it from a new file format called XYZ.hypeComponent. Imports would also overwrites the associated resources and remove the old ones.
Components could be UI elements or any other type of helper that get’s active when it’s dragged to the scene. The settings for the component could be made through dataset and wouldn’t be reseted when updating the component. The settings would be considered something exterior as they are attached from the “outside” when users is using the component.
For document level components/extensions they are currently hooked up to “document load” and “prepare for display” and mainly only a function. This could be another kind of component hiding the associated functions inside but as this isn’t a full analogy to the symbol based approach described above that part is still food for though.
Have you found a workaround for this problem?
Yes and I find designers are intimidated if they se the inner complexity of current extensions. Meaning if this is hidden like the runtime itself it would become more like a tool.
Are there examples of other apps with this feature? Or, have you seen examples of this elsewhere on the web? (Please include a URL)
As mentioned Mac OS with it’s app packages as an analogy.
How high of a priority is this for you?
High
[ ] Nice to Have
[x] Important
[ ] Can’t use Hype without it
To go step further on a full bundled world: I had another thought concerning document/scene level extensions . Extensions could have even another symbol like a gear or so and be something that can be dragged from the resource library to a drop zones on the document or scene level panels and listed there. These “bundles” would only contain JS and open much like a component (see above). The difference would be that they are not a symbol or component in nature and hence don’t open a timeline. They only filter down the resource library with associated resources. Updating an extension (copy and paste, import) could overwrite associated resource and functions much like updating a component described above. The JS functions in them get executed on the page level leaving developers to register for any Hype events as currently through the JS eventListeners.
There is the edge case of multiple documents on a single page using the same components or extensions… and if extensions are exported on a document basis into the resource branch of the individual Hype document, one get’s multiple copies of the associated resources of the components or extensions. That is not ideal… still not finished on that thought…
I would imagine the implementation we would go with would be these improvements to symbols:
they explicitly specify their own resources/javascript functions. (the UI is a little up in the air as there are a bunch of directions to go with the resource library for many other reasons)
They can have code that executes on document load, even if they are not in a scene. I also like the idea that it can hook into an On Prepare For Display if it has been instantiated on the scene. (these are two new ideas added to our tracker!)
They can have slots/fields that allow external configuration without needing to enter a symbol. This configuration can be read by javascript or bound to properties of elements inside. This configuration can also be animatable.
We had a long standing goal with Symbols to allow for constructing an image carousel. For this to work, there would need to be some special editor javascript as well - basically how to handle with displaying and dragging images onto the item.
I think these next-gen symbols would exist similar to today where they are per-hype-document, not per HTML page. Any code would use hypeDocument references/API to ensure it doesn't break on a HTML page with multiple hype documents.
As always, I’d take what your willing to offer but that sound great. My goal in the writeup was a solution that wouldn’t change to much and still offer the most. As the imagined components are basically “symbols with benefits” what you are detailing fits in nicely and I’d LOVE a way to attach custom panel JS or JS that makes the preview in the GUI look decent. Just hope that this is not to ambitious and gets stuck in the todo pipeline.
It is true there are a lot of items ahead of it in the pipeline, but having reusable building blocks (the image carousel example) has been on the drawing board since day one, and we did a full design of this for the symbols feature. We scaled back symbols a bit for the 3.0.0 release as we weren’t even sure if folks would understand symbols let alone use them and wanted to ship. Symbols has seen much more usage than we expected, and many other apps use symbols or analogs with varying degrees of this customizability. I guess this is my long-winded way of saying that the feasibility is high but time frame won’t be short term.
Especially if you have the option to control the global duration (and transitions if at all reasonable a task) of the images being dropped en mass, which I assume would be going on a timeline.
Jim it is not about Tumult building a slideshow. It’s about them giving as the possibilities todo so. So you’d have a drop zone and then you’d have to build the logic based on inner timeline animation built with placeholder oder DIV’s and then create the images switching logic yourself given the parameters you now got from the user as he dropped images and set some settings. I’d would be the best if we even additionally get symbol JS that runs only on the editor to make a live preview in the GUI work.
