The tutorial is well done and fluid is very fun to use. I love how simple it is to setup simple transitions and "play" the app.
Dragging a page into the trashcan is inconsistent with deleting an element by hitting the trashcan button; it took me a bit of frustration to figure out. There's no way to figure out what the buttons do short of clicking on them to figure it out. Most features are intuitive but as evidenced by the "Actually it looks to me like it's only for iPhone design." comment the UI could use a little more explanation (there's no rule against using an icon /and/ text for menu options).
I really don't understand why there are so many negative comments, this is very nicely done and I can see it being useful. I'll definitely give using it a shot on my next mobile project.
I too was impressed with the smoothness of the UI transitions, and the zoomed-out view. Engaging to play around with. Same confusion about menus - they jump around quite a bit, it's hard to re-focus on relatively small controls that are in a slightly different spot each time. I'm somewhat guilty of this as well, so take the feedback as you may.
Lots of templates, almost overwhelming. Looks great for detailed app interface prototyping.
I wonder about the code it exports - One of my goals with Edit Room is to have semantic, clean HTML and CSS that is as close to production-ready as needed, with skilled developers picking up the design prototypes, in close collaboration with designers using the app.
For more general communication designs, do check it out: http://www.edit-room.com (my project). It is perhaps more suited to the web design and publishing workflow. Edit Room takes up the task of complete visual design + prototyping. Inspired by AE and PS, but streamlined and focused on building high-fidelity, live, shareable prototype HTML/CSS documents. The visual design and animation editor generates flexible, responsive layouts that look exactly like what you've created on-screen. Etc... Oh, it works just fine with Firefox.
Thanks so much - The Edit Room looks very interesting, I like the immediate connection - will check it out some more. If you'd like to talk, drop me a line on ian@fluidui.com
With the trashcan there are two ways to delete a widget - you can drag the widget to the trash just as with pages or you can use the button in the menu if you want less mouse movement for the action. We thought in that case that offering both methods is optimal.
It's interesting that this is generally not frowned upon from the hacker community, even though only supporting Webkit is clearly the same fragmentation issue we've all been upset about for so many years.
I imagine if it was "Sorry, we only support IE9" you'd get a different reaction.
The reason that there's so much focus on web standards is because Microsoft used their browser to force platform lock-in.
I don't see going webkit only as being a problem: Chrome is available on the three major PC operating systems (Windows, MacOS, Linux), it's free and it's not owned by a PC OS vendor.
Now if it was Safari-only or IE-only, then that would be a problem.
The Chrome trademark is owned by Google. Webkit is BSD and LGPL [1], and Chromium is GPLv2 [2] and virtually identical to Chrome except for branding and some proprietary plugins Google doesn't control the licenses for [3].
So yeah, while you're technically correct by your wording alone, I'd argue you're wrong in spirit.
Actually, Chrome is not the same on all three systems. I can't remember the site, but a while ago someone wanted to share with me a site using advanced CSS3 transitions and it didn't work as expected on my Chrome on Linux (the latest beta version at the time). Only after switching to Windows and using Chrome there (the latest beta version too) I was able to see it.
I would say that we don't mind because we understand that there are many features on "modern browsers" that are not available on IE 9 and below, but yet are web standards (ok, not all the time). Hackers also tend not to use IE, so that also helps explain it.
It really only sucks for general consumer-facing apps to not support a large variety of browsers. Otherwise, for specific apps with more tech-savvy users, just supporting a couple of modern browsers is just fine IMO.
The problem is that this is the same argument about why we had the "only supports ie6" way back in the day (and ie5.5 before that).
While I don't think that webkit will stagnate the way ie did, it's really amusing to see the webdev community repeating the exact same arguments supporting webkit-only sites that we were about ie5-only sites 12 years ago.
Sorry to disappoint on the firefox front, we'd love to support it and we will as soon as we can, but we're a small startup and sometimes we need to make tough decisions about where we spend our time and resources. We'll get to it!
You could at least let me look at the site with a warning that my browser is unsupported rather than blocking me.
I can understand the view that this would make you look worse, but my personal response is that I don't want to give your tool a second chance because of the annoyance (if everyone says it is the best thing since vim, of course, I'll get over myself and look :P).
If it was truly broken in Firefox I would've been curious enough to try it in Chrome. Sorry.
Right now, being blocked like this, I'm assuming by default
- You sniff the UserAgent (didn't test) instead of using feature detection
- You're basing a product on non-standard web technologies and will, like Google does, later provide 'Please UPGRADE to Google Chrome' (emphasis mine) links all over the site, as on this FF landing page.
Worse: There's no introduction to the site at all. So the topic says 'Mobile Mockups', but I don't even see an about page, some introduction stories, images or whatnot. I end up with a bullshit message that tells me to install a different browser for a product that I cannot check out without doing just that.
There's not much room to present a product less favorable.
Please please please don't require a user of some sort to submit feedback - I don't need another set of credentials for this and you don't want more friction for users who want to help you out.
Also, please add tooltips for various icons - they aren't all self-explanatory.
Thanks for that - we wish anonymous feedback was an option - we use Get Satisfaction, it's a great service but it does require some form of sign in. We will keep your feedback in mind and maybe there are other things we can do.
Just asked one of the developers, they are working on it. There is nothing that stops the web site from working on FF other than additional testing and small fixes, which simply should be done, and is underway.
We are really sorry that you are annoyed by the lack of FF support. We will get to it as soon as we can - hope you might give Fluid UI a try at that point.
I think that google did a good job of providing chrome for almost all platforms, so I see it as a good cross platform deployment environment, now better than Java.
For most developers who will use such a tool it's not a problem to install a webkit browser.
I'm just amazed you use divs containing data-uri images instead of, say, a canvas element for drawing icons like the battery level and connection signal bars. You must have fought hard with superhuman patience to do battle with the DOM in this way.
I myself have neither the grit nor the will to endure what you must have suffered, but I recognise this amazing achievement. As another poster has said, you deserve your $29 a month for your effort. I take my hat off to you sir.
Safari and Chrome might both run webkit, but there are still significant differences in how fast they render and handle transitions for different things. In this case, both draw on canvas initially as you suggest, but chrome then uses toDataURI() to draw the canvas to an image as otherwise the scale/zoom transitions run unacceptably slowly.
I'm getting overwhelmed by all these nifty browser based prototyping tools coming out. Very cool stuff, but it seems like the market is starting to get a little saturated
I'd actually prefer a desktop app that does some of these things, considering I don't want to install Air for Balsamiq, and don't really want to do all my work in a browser, on a service that could disappear at any moment.
Sadly, I'm not the person with the expertise to do it.
Non-native, true. But slow? Balsamiq on my PC is nothing but snappy. You should consider sending a support request in case there is a bug in Balsamiq(or Air?) with your OS/pc configuration.
You can set any arbitrary size on a page (click the gear in the topleft corner of a page) and almost all of the widgets are suited for any prototype, mobile, desktop or anything else.
Clearly top-notch design and functionality, very impressive. I'm believe you deserve $29 a month for all your hard work, but I could never justify this expense. Again, the product probably is worth it, but out of price range for some smaller companies. I'm not looking to start a flame war about being cheap or not paying for quality work, I just want to give you a little feedback about pricing. Do you have any other pricing schemes in mind - one-off or limited functionality type deals.
I posted a similar comment on Reddit. We're a decent sized mobile dev house (around 20 devs), and $29 / month makes me think hard if it's really worth that money. At $290 a year it would be close to the most expensive piece of software we would use. I think at $5 - $10 per user they'd get so many more users that they'd make more profit. Just my opinion of course.
If you can't afford $29/month then you're probably not in their target market. If you used this tool to do UI prototyping as part of a mobile development project you could be charging companies $29,000/month which would justify the 0.1% investment.
Serious question: Where do you find companies that pay $29k a month? I'm trying to start a mobile dev shop with a YC alum and we haven't seen budgets anywhere near this.
It's actually fairly common. Large clients will pay high prices for great work. Sometimes it's hard to imagine as a developer paying that much for something you can clearly make yourself. Good developers are hard to come by. Great developers that actually deliver product on time and under budget are unicorns that are worth the money.
I know a company that's building a mobile app and they're paying $150/hour (one developer plus project management) to a dev shop. At 8 hours a day and 20 days a month that's $24K/month. Put in an extra hour a day and you're there. Of course, the trick is finding clients willing to pay full rate, but if you're good they're out there.
It's just 2 people, I'm guessing the dev gets around $120/hr and the PM $30/hr? A Dev and Project Manager? Can you PM me their portfolio/website please?
Project management isn't a full-time thing. A good PM should be able to manage a fair number of developers at the same time... you certainly don't need a full time PM per developer. Unfortunately I'm unable to share their info.
We're a mobile dev house (iOS and Android), and we charge around $60-$80 / hour. www.polymorph.co.za . Sounds like we should get some US clients if $150 / hour is realistic.
An experienced mobile developer working as an employee at a dev shop in the US should be able to make that kind of hourly wage. Considering the fully loaded cost of employing someone is between 150% to 200% of the salary (equipment, office, infrastructure, training, benefits, etc.), you're effectively working for as little as $30/hour.
Sure. Most of our work is actually for corporate clients, so not commercial apps found on the market under our name, but a few examples of commercial apps are:
Thank you to everyone for the excellent comments and feedback about Fluid UI. So many points of view and really excellent issues raised here - we love feedback, good and bad.
Just as a note, if you want to log any issues/glitches or praise our support forum is http://getsatisfaction.com/fluidui - we are pretty active following up there.
We will try to reply to as many comments here as possible.
Here is some sample output. This is a mockup that simply shows some of the Android ICS phone library. This is an example of the URL that you can output from the tool, including with a free account. QR straight to phone, email link and one-click social sharing.
I have to say, I'm pretty impressed. Yeah there are a few wrinkles but it's a great start. I can see myself using this. People seem upset that it isn't 100% fully what they would expect. Personally I think releasing it and using customer feedback to help improve it is the only really viable way to develop a product that your user base will be happy with. An impressive tool that I'll be keeping an eye on.
One thing this is lacking for me is a way to display page hierarchy or flow through the application. Just being able to connect pages with lines or arrows would be great. Or as a bonus it would be nice to be able to connect page elements to pages or elements on other pages.
Few issues:
* There is a problem moving labels in buttons/tables using the keyboard. Everything jumps
* The labels in editing and preview don't look the same
* Please add "Undo/Redo"
* Can't find a way to delete new window
I made two pages. They were overlapping (Not sure if this is intended).
When dragging elements onto the top page, they went to the bottom page. When I moved them around the top page they went to the bottom page.
We're doing a blog post on fluidui.com soon about the prototyping process that we used to build Fluid UI - we have the first infinite canvas prototypes that we made and we can include them in the post. That will explain it better :) Thanks!
Wow! I'm really looking forward to reading that post. I've been reading up on canvas and JS lately and am interested in seeing some full application case studies.
Our attention span is getting shorter and shorter -- an instant try-out with a "wow" moment is a necessity. Very well done, held my attention long enough and will refer to for future use
Really excellent piece of work. I've been using Omnigraffle for almost 10yrs and this is the first web-based tool that I've felt good about. Really great work.
Nor the iPhones.
Probably because in theory you shouldn't be designing to the DPI. Pixel values (frames, sizes, etc) are still the low-res values. It matches everything else you do with iOS devices (IB works at the low res, for instance), not sure why they'd need to differentiate them here.
Dragging a page into the trashcan is inconsistent with deleting an element by hitting the trashcan button; it took me a bit of frustration to figure out. There's no way to figure out what the buttons do short of clicking on them to figure it out. Most features are intuitive but as evidenced by the "Actually it looks to me like it's only for iPhone design." comment the UI could use a little more explanation (there's no rule against using an icon /and/ text for menu options).
I really don't understand why there are so many negative comments, this is very nicely done and I can see it being useful. I'll definitely give using it a shot on my next mobile project.