Just a heads up: that JS-induced header flickering is distracting as hell. Use `position: fixed;` instead of a JavaScript hack that constantly flickers the header in and out of the window.
I can't reply to the OP's reply, so I'll write it here: my advice is to give up on responsive design, particularly if it's giving you trouble. Why bother unless it's "free" (given to you by some premade design you're using)? In general you're going to have to design a page different per medium, so why make the technical implementation of that design more difficult on yourself by having responsive design as a constraint.
Sure, totally valid. I just built the site from scratch in simple HTML/CSS, so I figure this is a risk-free place to learn something new. I've been doing a lot of IA and product management for 18 months, so I'm catching up on the latest practices a bit.
Ya, :fixed doesn't behave as intended there. I tried it out on a 15" MBP, 13" MBP, iPad, Cinema Display, and phones, so I've seen that it's pretty cramped. I'm not great at responsive design yet, but I'll mess with it. Any advice on getting the images and text to scale to smaller screens within their divs would be appreciated.
On that note, can't wait to see how Polygon.com is built.
For images, you can specify either multiple file types (load different resolutions with media queries), or use .SVG graphics (support is spotty in older browsers). Here are two handy guides: http://bit.ly/LzRkfN and http://bit.ly/MH1bjq.
For text, it depends on which part. For body text (paragraphs), the easiest thing is to have a percentage based container and change font-sizes based on break points with media queries (e.g. at a screen with min-width of 768px, change font to this size). Headers are a bit different, you can follow the same approach as paragraph text or, use something like FitText (http://fittextjs.com/).
Love your work. Hit me up at me@ryanglover.net if you need code help.
I am curious about this too. After disabling javascript and fiddling with this for about 1.5 minutes in Web Inspector I was able to get it to behave like the JS implementation reasonably reliably. It would only have required some CSS cleanup to move the icons etc. back into place properly.
Ah, I see. The problem is that I'm an idiot and was :fixing the wrong div. For some reason it was collapsing ingloriously upon itself. Must've been a 3 AM hackjob.
Also, I'm gonna shrink the header for all of the content pages. Good call.
I changed it to :fixed and shrunk the header bar on content pages. Looks fine on the iPad. I need to learn more about responsive design principles, etc. before I rewrite it for phone resolutions.
In case any TripIt engineers/employees/etc are browsing, I do want to say that design aside, the biggest issue with the iPhone app is that API requests are made in the main thread, so the GUI locks up. It is incredibly annoying to tap on a page, have it be frozen, then a few seconds later the API requests finishes and it processes your tap which takes you to a SECOND screen which requires an API request, and you're frozen again.
TripIt should be one of those apps that is "open, read, close" in 10 to 15 seconds. The API requests are brutal, brutal.
> The biggest issue with the iPhone app is that API requests are made in the main thread, so the GUI locks up.
Wow, really? That seems like a major oversight. I'm pretty inexperienced in the iPhone development scene, but I know with Android development this sort of thing is strongly discouraged. There's even a mode called "StrictMode" where any file and network access on the main thread will cause a crash instead of hanging.
Ya that's what devs were telling me while I was working on it. Could loading the app on individual "event cards" with cached data, like I proposed, potentially "solve" that problem? Or is there a better way?
If there are no upcoming trips or cards, I designed an empty main Trips table to load instead. Was the least interesting of the comps, so I left it out of the site.
The main problem isn't a design problem, it's a problem of the developers being incompetent. Accessing network resources on the main thread is a massive beginner mistake.
Though pre-loading the card with cached data while the real data is being fetched is absolutely the best solution and experience.
> When moved to a slide-down tray at the top, you can jump between sections more quickly
I don't like when people are quick to skip over system-provided controls. In this example, an UITabBar would be a perfect replacement for the drag down menu at the top. What were the reasons for making it a custom drag down menu?
> Menus are Temporary
I don't agree in this case. The tabs in UITabBar are always visible so that the user knows precisely where they are in the application at all times. Furthermore, a user already knows how to use an UITabBar, whereas with this new control, the user has to learn to scroll down from the top to navigate anywhere.
> What were the reasons for making it a custom drag down menu?
It takes up so much valuable screen real estate! Though I haven't scaled it for the iPhone 5 screen yet. Path is a great example of skipping over system-provided controls.
> The tabs in UITabBar are always visible so that the user knows precisely where they are in the application at all times.
In TripIt's case, I disagree. I spend 90% of my time in the Trip section. Though if the Network section was more robust, there would also need to be some kind of notification in the top bar, too.
TripIt makes me sad. It had such huge potential and has almost entirely stagnated. The point tracker is frequently just plain broken, the app is indeed terribly slow (especially offline, the mode I'm usually in when I need it most) and poorly designed. They've essentially banked on two killer features: email itinerary parsing (no small feat) and alerts (which are very good). I wish they'd put more effort into the rest of the product.
Agreed. I find the Web site itself to be quite poorly designed, too: I often find it difficult to parse out the pieces of information I want from an itinerary from the pieces I don't (such as automatic directions).
Also, the permanent nag-bar at the top of each page because I haven't set up automatic importing (and don't want to) is particularly irritating. Plus, it can't remember my Google Apps domain, let alone my login.
I love the itinerary parsing, but wish I could love the rest of the service as much.
Same. The parsing is incredible. I feel like TripIt is in "acquired" mode, where the new owners are more interested in profiting on it than innovating it. That said, I've never met anyone from there – just reading the news.
Actually, there's another option as well. If you have the FlightTracker app for iOS (it's a great app, btw), you can configure it to pull your TripIt flights. Just throwing this out there.
That looks pretty good. Any plans for companion apps for other modes o' transport?
I didn't realize TripIt handled so much potential data, until I mapped out the whole app in Keynote to start this project. Credit where it's due – while I hate the existing app, it's still no small feat.
This is great! I work as a dev on a related travel product (mentioned in a comment here actually) and our in-progress redesign has the things you mention as priorities (speed/clarity).
I'm going to go ahead and say travel apps in general suck, so I'm not surprised to hear your sentiment towards TripIt's iPhone app haha.
One thing that I appreciate is that you understand the difficulty in designing these kinds of apps. On the surface it's "oh. well it's really just a bunch of lists and buttons with labels and text", and I think that's the approach a LOT of travel companies take. They value the tech/info more than the way it's presented. Luckily there is a LOT of room for improvement in this industry, and with devs who care about experience and designers who understand tech we should be able to make a big dent. I honestly thought TripIt would be one of those companies though...
Cool concepts. But TripIt's mobile app isn't as bad as you are saying. I can always quickly and easily get what I need from it. The mobile app is one of the few "pro" upgrades I actually pay for on any app and it is worth it for someone who travels 15+ times per year.
Which phone do you have? On my iPhone4 it lags and is slow all the time. I think particularly when it's in air plane mode but it might just be my perception.
Same here, I'm on an iPhone 4. Apparently it's just constantly pinging the server when you launch it, even in airplane mode. You'd think it would know to skip that. Will certainly be testing it out on the iPhone 5 when I upgrade next month.
I try not to go off topic and bitch about the site when stuff is posted like this, but sometimes being fancy can come back to bite you: on my 11" macbook each "slide" (if you want to call them that) doesn't actually fit on my screen. The header bar takes up so much damn space I can barely see the main content. A basic website with no frills that I could just scroll, using the maximum amount of real-estate I have available to me, would have been a much better experience for me. Sometimes simpler is better.
Agreed. I shrunk the header on the content pages to remedy that a little, but I'm still learning about responsive design to accommodate 11", iPad and phone screens. Feedback appreciated.
Clearly you've thought this through, and don't use eye candy frivolously; but rather use it for a purpose. This is a perfect example of design done right, and what can come out of a job when practical considerations are kept in check, and when the design is thought through thoroughly. TripIt would be crazy to not try to snatch you up on the spot—hell, any company should. If you're looking for a gig, shoot me an email!
Ha, thank you. I actually mapped out the existing app's "potential data" in a 51-slide Keynote before starting this, and the 11 iterations before it. Nobody will ever see that – it's just bones – but I hoped the thought process would show through a bit.
TripIt favorited my tweet to the link, but... that's it. I'm not really looking to join Concur. I'm just hoping they haven't quit on their loyal and loving users yet.
Thanks! The hidden nav is certainly a risk. The bumps on the bottom of the bar try to suggest it, but are very subtle. A major overhaul like this would involve some marketing efforts, and/or a NUX tutorial upon first launch. They'd lose that chunk of existing users who hate change, no matter what progress is made. I can picture the streams of tweet rage already...
Recommendations on clearer nav icons? Always seeking constructive feedback from people wiser than I.
Yaaa guilty as charged. My last iteration carried the same topography pattern down from the menu bar, but it washed the whole thing out. Lacked contrast. This seems deeper, more pleasing to the eye.
Trying it out – UX is super fast, easily superior on both iOS and web. The confirmation email parsing doesn't seem to be working for the first few I've sent in. Feels kinda like filling out an expense report. Gonna run this side-by-side with TripIt on a road trip next week, and see if I actually end up using it. Thanks!
