tumultco

Thanks!! :)

Thanks!

We get maybe 2-3 requests a week for Hype on Windows. My napkin math estimates of potential customers (those that don't write in or saw our FAQ, and then would go on to buy) shows this might lead to lower double-digit percent income coming from a Windows port. This roughly corresponds with our site traffic, which is 18% Windows users.

My general thought is (at this time) we’d do better to develop enticing new features to expand our user base than doing a Windows/web port.

One of the founders of Tumult Hype here --

When we started out Adobe was still sticking to their Flash guns. As HTML5 was the only method to make animated web content on iOS, it was clear someone needed to make tools aimed at graphic designers, so we decided that someone should be us! Luckily with no other competing apps around, we didn't have to deal with an uphill battle on feature parity unlike these vector editors do with Illustrator. So I wouldn't say we were disgruntled, just trying to fill in a hole. And, on a personal note I had a need for such a tool for a side project I was working on.

OS X is a great platform to develop for generally speaking. We naturally leverage WebKit, and Quartz and CoreImage frameworks I'm sure do a lot of heavy lifting for the vector-based tools. Also keep in mind a larger percent of graphic pros use a Mac than the general population, so if you're building a tool it is a safe bet to start on the Mac.

Some path components are not made for humans, but many are. I regularly type in twitter.com/ and a user name or apple.com/ and a product. Or on GitHub I'll change the page number in the URL to advance 10 pages. Also, domain names can be just as noisy with subdomains.

How do you define an average user anyhow? I think there's only more common use cases. Everyone has their special needs and uses on the internet.

I'm curious if there have been studies about people not caring about the URL or showing it is a more of a usability hinderance than help. I remember arguments about this back in the late 90s (some suggested VRML navigation as a solution!), and the web has still seemed to take off despite no significant changes to the URL bar before the last few years.

In your example, wouldn't the "BC" be the domain name and not "Starbucks?" I don't know if there's any way to know with certainty in all URLs whether the domain name or the path components are more important to a user.

Thanks for reporting this; our site should be able to handle this amount of traffic no problem and the video loads pretty quickly for me. Where are you located and does the problem still happen?

We've moved nearly all of our other videos to youtube, so if it really is our server you can click the "watch more" buttons on the main page to still get a feel for the app.

Google itself doesn't scare me; it is really just team vs. team. I think we've got the best product and engineering expertise for this market. Clearly I'm biased :) so I'd encourage anyone to try Tumult Hype and let us know your thoughts (we've got a fully functional 14-day trial on the site).

While Google hasn't announced pricing, it is probably safe to say it is going to be free. This is a business for us, so we charge $29.99. I don't like competing against free, but that just means we'll be continually pushed to provide that much more value!

Yes, we ultimately felt it was a fool's errand, especially because we're a startup with limited resources so we need to focus on the right problems. When we launched version 1.0 long ago it seemed like this wasn't necessary for a "minimum viable product" considering we're targeting graphic designers who might not have as much coding experience anyways.

There hasn't been much that's swayed us otherwise -- I think it was the right call.

That's the purpose of my startup :); we've been making an HTML5 animation tool for OS X for the last two years:

http://tumult.com/hype/

It looks like this is based on the Ninja Authoring Tool which is an open source project, but also Google would have gotten as part of their acquisition of Motorola Mobility.

http://arstechnica.com/information-technology/2012/07/ninja-...

https://github.com/mikestowe/ninja

This appears to be a fork of the Ninja Authoring Tool which was made by Motorola Mobility over a year ago as part of the Montage project. Now Google owns Motorola Mobility.

http://arstechnica.com/information-technology/2012/07/ninja-...

Tumult Hype's exports are essentially 3 lines of HTML so it is easy to embed in other documents and output mostly takes the form of JSON animation data and a JavaScript runtime file. It isn't meant to be hand-edited or even read, since we minify heavily to keep file sizes extremely small.

While everything has its tradeoffs, we went with this approach because:

- Our app has a lot of animation and interactivity capabilities not meaningfully expressed through anything but JavaScript. For example, we don't use CSS3 Animations nor transitions because they aren't powerful enough (pausing, synchronization, etc.).

- We have better control over how we express the DOM to the browser. There's plenty of browser bugs or incompatibilities which sometimes require us to on-the-fly change the DOM structure or which properties we are using.

- The user could easily bork the output so it could not be read back in

- No tool will ever produce output that will appease everyone :)

We provide lots of hooks in and outside of the runtime for your own JavaScript and HTML so you can still customize quite a bit.

So it isn't that our output isn't very clean (in fact I'm quite proud of the runtime and how we've been able to add features without increasing bloat); it is that edits are meant to happen from the app itself.

We're trying! http://tumult.com/hype/ :)

We do distribute and sell independently of the Mac App Store, which allows us to offer trials, lets users to easily convert the trial to a licensed copy, and provide bulk or educational discounts. Even with that, ~80% of our revenue has come from the Mac App Store. Users want and expect software to be available on the Mac App Store; I'm sure the support volume we'd get by not being there would far outweigh any we've seen from this bug.

Sandboxing was a technology that did not exist (and therefore was not required) when we started selling on the Mac App Store. This came later, and became a requirement to push any updates containing features.

Lots of mac developers have complained publicly (or privately to me) about sandboxing. Many others have not been able to issue updates, removed major features, or simply removed their apps from the store. There's plenty of information on this on blogs or the developer forums, though many would not speak out publicly against the hand that feeds them. The apps that do well with sandboxing are naturally those which do the least. It would have been easier for us to neuter our app, but we've taken a strong approach to working through all the issues and avoided removing any major features. It would be unfortunate if innovation was sacrificed for security.

We originally planned to have our non-MAS copy not be sandboxed. This creates complications and other bugs for users when offering both versions based on how the sandbox container is maintained and that any bookmarks (aliases) kept cannot interoperate between the two. From all the tradeoffs we see, fully adopting sandboxing is the best option. But, that won't stop me from complaining about all the bugs!

I've shipped plenty of embarrassing bugs in my days! And, had I shipped a bug that likely has to do with escaping characters improperly, I too would have been embarrassed by it. But beyond that, as someone who spent many years dealing with integration testing of Mac OS X, this is the type of bug that would make me cringe that our infrastructure was not setup to catch it.

We reported this to Apple (that's what the rdar:// link is for, to add to the Radar bug tracking system). The "embarrassing" perhaps stems from our frustration and months of dealing with similar issues, but is something that should have easily been uncovered if apple did dogfooding of the technology before forcing it on developers.

I wrote it up as more of a public service announcement to other Mac developers who might be encountering the same issue.

There is a webkitTransitionEnd callback. But it alone isn't sufficient for complex animations that could be made with Tumult Hype.

I didn't go in with any assumptions. There's been lots of advice given that using transform:translate() is always the fastest path; the point of this was to measure and see. Also knowing something is faster isn't the same as knowing how much faster. This can have implications when deciding what technology and tradeoffs to use.

Besides, is it really obvious that top/left would be faster (in a non-transition case)? It requires an additional layout phase compared to transforms:translate().

On the common sense of transitions being faster, it is true that there will be overhead in running JavaScript code. But at the same time, 1/60th of a second is a very long time for a computer and (for me) the overhead of crossing the bridge and running a minimal amount of JavaScript was an unknown.

Being from the "show me state" I like to measure before doing any performance optimization work or making general claims.

The quoted description sounds much like a horoscope, and I'm sure applies to many people who would not make great product managers. There's few ambitious people who don't want to own the product.

However, if you do "naturally gravitate to product management" -- that is you find yourself in those roles or have been assigned to those roles without effort or conscious action -- then it is a good sign of fit.

I've often speculated it may be based on how you are brought up. If you value charity, engineering, and redemption then Bill Gates (of today) is more suitable. If you value creativity, strong will, and charisma then it is Steve Jobs.

I do not disagree with the sentiment; it is useful to immediately know if there's been a bug introduced that might slow down your work and you may be in a good position to offer suggestions to fix. But also consider:

- If the bug is a regression it may stem from the author's misunderstanding of the codebase. By being the one to fix the bug they have a chance to learn correctly how it works and reduce future mistakes.

- The original author of the bug was just in the code and can likely most efficiently fix it since they are recently familiar.

- It would be wasteful to have two people working on the bug at the same time (though bug policy can also help with this).

- On a large project there can be lots of noise which does not affect you, especially if the project is well compartmentalized.

- Taking responsibility is always a good thing!

It is only toxic when people start pointing fingers and shifting blame instead of helping out. As a "component owner," I personally like to fix my own mistakes so I can learn from them.

Blood, sweat, and tears :). It was part policy, I wanted to keep HYPE.js below 40 KB which is important to some markets (advertisers) and didn't want to slow down the web.

My best recommendation is to always use Google Closure Compiler. By default it doesn't work much better than other minifiers, but there's an --compilation_level ADVANCED_OPTIMIZATIONS flag that can have a dramatic result. To use this, it is likely you'll have to structure your code differently and make sure exports work correctly, but we were able to take reduce a further 50% with this one change. In this release, we also changed a few other flags (in the code itself; there are no command line settings) which we thought would be advantageous to our file and userbase.

We also do a lot of string replacements. I built a simple templating system that glues files together and also can replace descriptive, programmer-friendly, key names with single letter variables. Strings can weigh a lot. In this release in particular, I also looked at the minified JS and examined which strings could be partially combined. For example, "rotateY(0deg)" and "rotateY(10deg)" could both have the "rotateY(" extracted and save some bytes. It matters less if you're using gzip compression, but we can't guarantee that among our users. The key is to make sure this doesn't make the code hard to read or edit in the future, and only tackle the most significant changes.

Not quite related to the HYPE.js runtime, but we also focused on reducing the entire export data size, including the JSON animation info. We again used a lot of string substitution -- "startTime" and "duration" in code simply become "s" and "d". With JSON, depending on the key name you might also not need quotes around them, so for an animation object it could be {s:1.2,d:3}. The quote characters can add up! There's lot of other things we did such as not exporting the common/default values since we could figure this out if the key does not exist, and being smart about element id's so they would not be some long UUID.

I just made this move a couple days ago after DreamHost silently dropping emails, among their history of outages and server restarts. Comparing the two, I was surprised at how fully featured DreamHost really is, but aside from a few small things the migration has been smooth and I am hoping uptime will be better.

It is probably named the same as many other popular products; "spark" is a common english word. With 7 billion people on this planet it is impossible to avoid naming collisions if you're going to use something from the dictionary.

I agree, I'm unsure of what the hook is for someone to download the mobile app and use it. Perhaps it would make sense if human.io came as a framework developers could import in their existing apps?

With this, they could potentially send out notifications to just their audience when participation would be useful. Completing tasks could also be a micropayment allowing the developer to give the user some sort of reward (like unlocking bonus features).

As a developer in the same boat, I can say I'd love to give users the ability to migrate licenses, even if it means losing a little bit of money for their happiness. Unfortunately Apple only provides 50 promo codes per version, and they aren't intended to be used for this purpose. I'd send feedback to Apple asking that they change their App Store/policies to support this.

Fantastic site! It'd be great if there was more metadata ahead of time to such as:

- Memory management model (ARC, GC, or refcount)

- Min/Max OS X version or SDK

- If it is sandboxable

It'd also be fun to see a list of projects which use the controls.

Nice mustache! Here's some other Foundation classes/methods which are very useful but lesser known:

NSCountedSet - and NSMutableSet that keeps counts of objects added

NSValueTransformer - More of a design pattern for generically converting objects

NSArgumentDomain in NSUserDefaults - command line arguments of -key value become user defaults

NSXMLNode nodesForXPath:error:/objectsForXQuery:error: - run XPath or XQuery against XML... even better, subclass NSXMLNode and then use XPath and XQuery on any hierarchical data you have

NSObject's performSelectorOnMainThread:withObject:waitUntilDone: - use NO for waitUntilDone and the method will be called at the end of the event loop (I've seen many people use the afterDelay variant instead)

NSNotificationQueue - use NSNotificationCoalescingOnName to batch up NSNotifications to send a single one at the end of the event loop, though there's lots of gotchyas for using it correctly

NSOrthography - Okay, even I didn't know about this before re-glancing at the foundation reference :)

I only use it in cases where an underlying framework does not expose or provide the functionality I need (and subclassing is not an option). I wouldn't necessarily say it means these frameworks are not well-designed though.

This is a comprehensive list of many considerations. Top of the list should be to have as small of an API as possible. API is forever. If you expose too much up-front then it increases the surface area of getting things wrong, which developers will be stuck with for a long time or need to deal with eventual deprecations which is fun for no one. Also, more API leads to higher complexity in learning. It is better to see how your API is being used and slowly reveal more functionality as you become confident it is what developers need.

I also believe API should go through a feedback/review processes with peers. Other developers will have used different patterns, have a different base of experience with the platform, and can generally help find common mistakes. So, here's some of my feedback/nitpicks on MGTileMenuController.h :) --

  @property (nonatomic, weak, readonly) id<MGTileMenuDelegate> delegate; // must be specified via initializer method.
  - (id)initWithDelegate:(id<MGTileMenuDelegate>)theDelegate;

It is very rare for delegates to be required for initialization, and I don't see why the @property for the delegate needs to be readonly? Perhaps an owner would be a better model?

The isVisible property looks like this:

  @property (nonatomic, readonly) BOOL isVisible;

But typically for BOOLs the property is the normal form with a specific "is" getter:

  @property(nonatomic,readonly,getter=isVisible) BOOL visible;

  // N.B. All of the following properties should be set BEFORE displaying the menu.

This makes me wonder what happens if I want to change them later? It seems that they should always be able to be changed, and in general comments shouldn't be required to understand library behavior as they'll just be missed by developers anyways.

  - (NSInteger)nextPageNumber:(NSInteger)currentPageNumber; // zero-based pageNumber

Why would the nextPageNumber not be +1 from currentPageNumber? Also, why do I need to supply a currentPageNumber when it appears currentPage is a @property of the class? Is there a difference between "currentPage" and "currentPageNumber" as their naming indicates there might be one? Also, it might be better to name the method similar to the NSIndexSet convention "indexGreaterThanIndex." Should an NSIndexSet actually be used instead?

  - (UIBezierPath *)_bezelPath;

This method looks like it is private/internal because of a leading underscore, so it shouldn't be exposed in the header. Also, Apple has reserved naming methods with a leading underscore (especially important when you are subclassing!). https://developer.apple.com/library/mac/#documentation/Cocoa...

In general, if the developer doesn't need the utilities, I highly question adding them to the header since you'll be responsible for them for all time.

Finally, why not add the delegate protocol to the header file so everything is consolidated for the developer using the class?