Very small item:
A stroke affects an object’s width. If you add or change a stroke, it can throw off the object’s center. It is possible to define an offset, but this should not be necessary.
I suggest that the stroke be set to inside, outside, or centered and that it not be included in the calculation of an object’s width.
I’m not sure I understand what you mean when you say ‘stroke’, are you referring to an rectangle’s border?
Yes. The standard approach in illustration apps is that while a stroke can be assigned to an object or a part thereof, it is not included in an object’s measurements. There are a number of good reasons for this, such as when resizing / aligning elements of the same dimensions but different stroke widths. Another handy little feature that would work well with this would be a 3x3 grid icon for instantly selecting the XY reference point to a corner, edge, or center of any / all selected objects.
Oh man, I love Hype but do I_miss_this
But the 1px or what ever has to come from somewhere.
I think you either make it auto adust position. Which I think is bad or you have to adjust manually. Which is the better option if a pain if you do not realise what is going on.
Adobe Illustrator has been doing it since 1987. With Flash, a stroke is not part of the measurement unless you decide to flatten the object, but when you do, the position is automatically offset to appear the way it was intended.
Functionally, a stroke is not real until it is rendered. When rendered, the program decides how stroke relates to the position of the object. Obviously there are other things that factor in, but there is no hard and fast rule that states that a stroke must be included in the measurement of the object to which it is attached. It can work in any way that the programmer wants it to work.
I would like to hope that eventually Hype will eventually support vectors, including the vector-based approach to strokes.
This seems odd to me to not know until you are done the size or how close elements are gonig to be to each other.
I guess if you are used to it, you are used to it. I do agree that maybe an option for outside, inside or centered border would be good.. I am not sure I agree that if it is outside or centered it should not count to width. This does not make sense to me.
But then I do not come from a illustration background so maybe thats why I am missing why you would want this!.
You do know, all the way through the process. No matter how you may change the stroke, it does not affect an object’s position.
And if you need to adjust the stroke (such as a bolder stroke when an object is at a smaller size) doing so will not mess up the object’s position.
There must have been a good billion or so documents created this way over the past thirty years. You will not find anything created with vectors that does not do it this way - virtually every printed piece generated since the early nineties. I have around five thousand on my machine at work and it is not my main app - (somewhere around ten or eleven).
This is largely a right-brain / left brain deal.
Yep, I did thousands of documents in Illustrator and there was never any issues for me, it was just something you worked with and had no reason to worry about. But I get the point made by those who have not used it. I dont do that much original artwork like I did in screen printing of garments. And I dont like Adobe any more, they used to be the be all and end all for me.
This is what I am getting at
When they went subscription they lost my business. I’ll still be using CS6 MC. I’ve got (and recommend) Affinity Designer and Photo but I haven’t made the transition.
For situations like this in Illustrator there is a menu command for outlining the stroke, which turns it into a solid object.
I would think it would depend on which would be used the most. Offsetting an object is easy enough. Frankly, I run into the width / shift thing with some regularity.
Same for me on the Affinity products. They look great, but one thing I have noticed on many apps is that when whatever are you are using now, and whatever you are switching to have similar, yet different interfaces and tools, the transition can be harder than you think. Exactly whats happening on my day job when the operating system and apps are mandated.
One easily gets caught up in the race for deadlines and taking the time for learning new stuff requires discipline. That’s the way it is for me and JS. I was a fire-breathing wiz at Lingo (including a complex educational game project that sold 80K units), but the differences with JS are enough for me to put off learning. There is also the left-brained approach to using JS in Hype that is not clicking with my right-brained mind. There are certain things with using JS in Hype that work better than Director’s approach, but I found Director’s approach better overall. Part of it was that it was smart enough that you didn’t have to worry as much about the nuts and bolts in having to manually assign this and that. Drop a script to an object or keyframe and move on.
If you add a border to an element in HTML, it will offset from that border.
In general, we try to approach controls via how the underlying HTML technologies work. This may not be as intuitive as how some apps have done strokes (there’s plenty about HTML and CSS to argue against!), but in general going against the HTML grain always causes problems for users coming from that background and also for us as tools makers.
There are a few things we do, like if you change the border from the inspector we will try to keep the top/left position “stable” while making the border, but ultimately it is also changing the top/left position to do this.
As far as if vectors were added, this will still be a little bit of a problem since SVG and Canvas do not support changing stroke positions from inside, center, or outside. Last I saw there was a proposal to allow this for SVG, but until that is accepted and widely adopted by browsers centering is all SVG can do. There are some neat hacks to simulate the stroking style, but probably aren’t ideal.
The following is in the spirit of the proverbial intellectual discussion. (I lived among the Brits for years and I learned to really enjoy a good back-and-forth. This is because it’s not about winning a debate but rather because the product of the exchange – which ever way it may go – can be very informative for all involved.)
There are several other points that might be relevant to the discussion:
Is Hype a creative app for scripters/programmers or is it a creative app that offers excellent support for scripting?
Clearly, Hype was developed by scripters/programmers and not creatives, so it would obviously be intended for and seen by the creators as the former. This being said, I wonder what is the ratio of Hype users between of creatives and scripters/programmers? Do the JS users of Hype outnumber the creatives?
My guess is that by some degree the creatives (including those who want to develop their JS skills) outnumber the others. Coming from a creative background, I would describe Hype not as a programming app for producing interactive animations, but as being a creative app for producing interactive animations. This is because one could postulate that at its most basic level, Hype is a visual communication app.
As for being friendly for those with a strong web background and for following the norms, I definitely see your point. This being said, there are many things that people do on the web that were not in the original spec.
I tend to take a right-brained approach to finding balanced solutions. If this approach were taken, I would suggest that the ideal all-round solution would be setting the external measurement of a stroke / border as the default, while also providing the option for center / inside.
As leaving things at the default would require absolutely no action on the part of the scripters/programmers/web folk, this would make it a non-issue, while having the other two options would work best for the creatives.
At the risk of being slammed as an anti-establishment Picasso / Dali / Warhol freak, I come from a background where overcoming theoretical barriers is like E E Cummings overcoming punctuation. It is a background where pushing an app beyond its intended limits is a great way to make an impact on the masses.
The hassle of programming this feature aside, I don’t see it as a revolutionary notion. Most creators of visual content in the world are not scripters but creatives (probably a ratio of at least 50 to 1). Recognizing that the shift is towards the web, and seeing that more and more creatives are learning to code and script, I would think that tossing this kind of a bone to the creatives would be reasonable.
Naturally, my view of things is influenced by my personal experience and background. One thing that I see from my years in marketing departments for consumer goods and services is that, if forced to make a choice, most companies in that category would choose a creative with web skills over a web person with creative skills. This is based on the notion that marketing is more about the visual and affective appeal than about appealing to the intellect. (Think about every print ad, web ad, and TV spot you see on a given day. Affective rules. Even so, the cleverness of what is presented is what pushes it over the line, be it achieved through visual design or scripting.)
This goes back to a restating of the previous question: Where are the majority of Hype users coming from - creative or back-end? It would be interesting to find out.
It would also be good to hear arguments against this position. No doubt, creatives like myself would learn something.
Hopefully this from the top of our Hype Pro page helps clarify our feelings:
I do agree it’d be nicer if the top/left were stable - that’s why we do the automatic centering when changing through the inspector (which I believe has been there since v1.0!). The idea is that while the dimensions are actually changing, visually it is not, so we’re trying to get the best of both worlds. I’d like to think the bone was tossed 
.
Ultimately there’s a grain to the web. Going against it causes pain for us and users, especially those who might be using code that can push their creatives even further. Hype’s existence is due to the emergence of the HTML5 medium. Flash went against the web (for good reasons at the time), but look where it ended up ;).
Let me give a specific example. CSS3 supports 3D transformations, so Hype has Y and X rotations. These surfaces could intersect, which as me putting on my visual designer hat, realized wouldn’t be ideal in most cases. The only solution at the time was to put each element in another container element when being rendered. Someone viewing the document wouldn’t know about this, but if you’re working with the HTML itself it is a huge pain! Even simple code operations like changing the zIndex of elements require knowing about this inner working detail. You can find lots of forum posts about this. Further, there’s a good chance doing this hurts performance of some Hype animations. It also is a bit of additional code to deal with the containers in the runtime, so not only does that increase file size (important for many of our users like ad makers), but also means improving Hype is more difficult. It wasn’t worth it.
When we do go against standardized technologies, it is for a highly significant win. Our animation system is more sophisticated than CSS Animations (or even the newer Web Animation API). Other reasons may include compatibility for older browsers. But we try to keep this as rare as possible.
I don’t think there should be a hard line between programmers and non-programmers. A great visual designer may need to learn some code to achieve certain effects. For example, learning the CSS box model is really important when working on the web. I guess my point is that I know artists care about their tools - and HTML is part of the toolchain when using Hype.
Thanks, Jonathan.
It is possible we might be talking at cross-purposes.
For me the problem that is sometimes encountered along the purely practical lines of how a simple change in a border width can require a series manual tweaks with a bunch of objects within a hierarchy.
There have been times (such as with a multi-tiered Q&A animation I did a while back, floating text and art labels on a map I did last month, etc) that can require the user to tunnel down through a complex stack of items while turning all sorts of things off, moving to specific times in multiple timelines for things to become visible, then remembering to turn them all back on, and then having to repeat the whole process for each breakpoint.
Having to create a script to handle such a complex things would take a lot of work, while having to do it manually would increase the likelihood of missing something (which has happened with me on more than one occasion).
This is why I suggested default settings that support the standards you mentioned. The programming of a button to change stroke centering (such as from outside to inside) would not violate that, but rather it would involve inserting a calculation that compensates to maintain the proper XY position.
Example: a 52 x 52 box with a 1 px border is placed at a position of 99 x 99. The user clicks on a “inside stroke” button (whatever it would be called). This does not actually create an inside stroke but changes the size and position of the box to compensate into a 50 x 50 box at a position of 100 x 100. Increase the “inside stroke” to 2 px and the box shifts to 48 x 48 at a position of 101 x 101.
To outward appearances it looks like the border has switched to the inside, whereas in actual fact the size and position of the box have been shifted.
This wouldn’t violate any rules or standards. Not to make a bad pun, but it is the reverse of “out of the box thinking”.
Certainly, I defer to you. I think I may be too heavily influenced by that George Bernard Shaw quote about why and why not. I’ve pretty much made a career out of coming up with new stuff by using apps in ways they were not intended.
Gotchya - you’re right that we could change the centering behavior in the editor without changing the under-the-hood representation. Good idea - I’ve added it to our feature tracker!
