Subfolio and nginx

I recently migrated my website away from Apache to nginx for performance reasons. The majority of the sites hosted on my server run WordPress, which was easy enough to get working easily under nginx’s rewrites. The one application I couldn’t get running properly out of the box was Subfolio, an application I use for uploading client galleries for proofing and download. I’m posting my configuration online in the hopes that it will help other Subfolio users wanting to use nginx.

    # Subfolio
    # Pass all .php files onto a php-fpm/php-fcgi server.
    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/tmp/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }
    location = /login {
        rewrite ^(.*)$ /engine/index.php?kohana_uri=$uri last;
    }
    location = /logout {
        rewrite ^(.*)$ /engine/index.php?kohana_uri=$uri last;
    }
    location /hash {
        rewrite ^/hash/(.*)$ /engine/index.php?kohana_uri=$uri last;
    }
    location = /denied {
        rewrite ^(.*)$ /engine/index.php?kohana_uri=$uri last;
    }
    location = /notfound {
        rewrite ^(.*)$ /engine/index.php?kohana_uri=$uri last;
    }
    location ~ ^/engine/(config/settings|config/users|engine/application|engine/modules|engine/system) {
        return 403;
    }

    location / {
        index  /engine/index.php;

        if (-f $request_filename) {
            # translated into "if the request is an existing file, break (do nothing)"
            break;
        }
        if (-d $request_filename) {
            # translated into "if the request is an existing directory, break (do nothing)"
            break;
        }

        # the request is not an existing file or directory
        rewrite ^/(.+)$ /engine/index.php?path=$1 last;
    }

Hope it helps!

Apple/Google spat over iOS applications benefits nobody, hurts users

It’s been known for a while now that Apple has removed Google Maps from iOS 6, Apple’s mobile operating system for iPhones, iPads, and iPods. This hurt users who frequently used the Maps application for public transit, as the new app is said to launch without the ability to route via public transit.

News came today that Apple is also removing the YouTube application from iOS 6. Apple issued a statement to The Verge stating:

Our license to include the YouTube app in iOS has ended, customers can use YouTube in the Safari browser and Google is working on a new YouTube app to be on the App Store.

Most people will agree that the mobile web view of YouTube in Safari has been superior since the introduction of HTML5 video on Google’s popular video host. While playback of individual videos is definitely better, I disagree that the experience overall is better. For one, the YouTube app fits seamlessly into iOS, matching the styling and UI components that have been used since the iPhone launched. The YouTube mobile view is kludgy to browse and navigate, obviously lacking the iOS-native tab navigation at the bottom of the window. For browsing various videos and channels, I prefer the YouTube native app for this reason.

Google is free to build their own application to replace the app Apple had been building and maintaining – not that Apple had done much with YouTube.app since the launch. However, this does present a few cases where the user loses.

Apple does not currently provide a way for an app to be the default handler for URLs, e-mail, music, or other destinations. This means any link sent in an e-mail will load into Safari. For watching the video, this is probably just fine – a lot of people seem to prefer the mobile view for watching videos as it doesn’t require you to switch contexts to a new app. The downside to this comes when the user wants to take action on this video – say to save it as a favorite or to add it to a YouTube playlist. The user either needs to log in to perform this action, or already be logged in. If a user tapped a link that launched Mobile Safari, this is probably okay; but for apps that have a built-in browser (like Tweetbot), the user doesn’t have access to the same cookies, meaning for each app utilizing the UIWebView, the user has to log in again as cookies are not shared between Safari and UIWebView.

Apple’s war with Google has only hurt one party – the user. Google is still able to create native apps and drive users to their website via mobile web views. Apple still sells their devices with new features. Users lose both features and integration with the loss of the transit navigation and native YouTube app, having to be at the mercy of Google’s iOS development teams. Those teams have been exceptionally slow on releasing iOS versions of Android apps – the Google Drive app launched well over a month after the service, and failed to meet expectations, providing a read-only access to your files. The iOS native GMail account was poorly launched and poorly received, as it is basically a UIWebView wrapper for a mobile view.  Google’s social Google+ app also proved to be a limited set of functionality in a buggy app, and it took Google nearly a year to launch an iPad-specific version.

I know Google can build a proper YouTube application for iOS – I just have my doubts about how well they’ll do it and how long it’ll take to go to release.

Why Foursquare dumping Google Maps is good for the web

Open Street Map - Salt Lake City

For years, the dominant force in viewing, generating, and manipulating maps has been Google Maps – and for good reason. Google has spent a lot of time making sure their maps were up-to-date as well as integrating their maps into iOS, Android, and the web. Initially, the Google Maps API was free – allowing developers to integrate Google Maps into their websites and web applications at no cost to them. In 2011, Google introduced limits on the number of API calls that can be made for free, and set pricing for API calls over those limits. For smaller websites that don’t use or display Google Maps data very often, this isn’t a huge issue.

However, websites like Foursquare that depend on rendering locations on maps as the primary purpose of their site, things can get expensive. Apps or websites that are using the Javascript API with 100,000 API calls a day or more could be shelling out at least $300 a day. For half that cost per month (as compared to per day), open-source powered MapBox provides 150,000 API calls/map views a day, and without Google’s branding and custom analytics. The cost difference alone is a huge selling point for using MapBox over Google Maps.

Cost savings aside, there’s one awesome benefit of using MapBox – open source software. MapBox heavily contributes their source on Github, for everything from custom map builders to Javascript frameworks for using map data. That’s not even the best part about MapBox, either. MapBox uses map data from OpenStreetMap, an open-source project that’s currently collaboratively building some of the most detailed maps I’ve seen on the web. The project is so successful, that it’s threatening Google’s grasp on the mapping market – even to the point where a Google IP address associated with a Google contractor was caught vandalizing OpenStreetMap’s wiki-like map project’s data.

So why is the OpenStreetMap good for the web? It introduces more competition to the mapping market, keeping Google from setting their pricing however they feel like, rather than based on the cost/demand of the product.  Additionally, more competition typically brings about better products, combating the tendency for the dominant force in a market to stagnate and cease innovating. Bing Maps, MapBox, and OpenStreetMap hopefully will continue to spur Google to improve their product and make it more affordable for developers and companies to use. Users can submit changes and fix map issues on OpenStreetMap, making it a better and more accurate map with each edit. I’m eagerly watching MapBox and OpenStreetMap grow and catch hold on the web.

If you’re a developer wanting to use map functionality in your application or website, you should look into MapBox and OpenStreetMap for your application or website. There’s already an iOS replacement for MapKit – RouteMe.

Could 500px’s new design be the death of the site?

Photograph: 500px is dead by Andrew Houser on 500px

500px is dead by Andrew Houser on 500px.com

500px redesigned their website today – much to my dismay, it’s a horrible design from the standpoint of modern web design. 500px has now strayed away from their original audience and goal of hosting and sharing the best in photography, and turned it into a social media hub with striking similarities to Pinterest and Facebook.

Rather than focusing on the goal of their website, they seem to have shifted priorities to social interaction on the site – the once portfolio-like URLs for users (e.g., http://500px.com/spangborn) now display the “flow,” a stream of activity on the website that more resembles a Facebook timeline/wall rather than an exhibition of photographic work, which is pushed off to a secondary page (http://500px.com/spangborn/photos). On top of this, the flow seems to only be enabled for a subset of users currently. The site also appeared to be having load issues immediately after the launch.

From a UX perspective, they’ve also made the mobile experience particularly painful. To see what I mean, grab your iPad and pull up one of your photo pages in landscape view. Click “edit” and try to scroll to the bottom of the modal window that pops up. You won’t be able to. Even after closing the modal, you’ll be unable to scroll the page. Additionally, the drop-down menu in the top right corner is near impossible to get to work properly on a tablet or mobile device. Tapping it once will sometimes pop the menu open, with a high chance that it will immediately close again before you have a chance to select a sub-menu item. This makes me wonder if 500px rushed this release out the door without testing in an attempt to steal Yahoo’s thunder before the new Flickr design is released.

This redesign didn’t bring all bad things, however. 500px has added a market for photographers to be able to sell prints and digital copies of their photos. Sounds great so far, right? Wrong. They’ve set the pricing scheme at something ridiculous. A 24 x 36 gallery wrapped canvas print comes to $500. You didn’t read that wrong – five hundred dollars. This normally isn’t a huge issue, but they’ve missed something huge. You can order the digital copy of the print (high-resolution) for $2.99, and print it yourself elsewhere for cost. Well that seems a bit ridiculous, but maybe the photographer can set their own prices? Nope. Pricing is set exactly how 500px sets it. It’s not even clear what the photographer makes from this purchase – I couldn’t find any documentation on it at all.

It’s clear that 500px has a lot to learn about the web, in aspects ranging from responsive web design, user experience, software testing, and working with photographers whose livelihoods depend on the sales and profit of their photographic work. If these types of mistakes continue to be made, it’s highly possible I may decide to cancel my renewal of their “awesome” account features and head to greener pastures. Their “awesome” features have been rather lacking anyway. This gives Yahoo a real opportunity to build Flickr into the service and photographic portfolio site users have been wanting, but I’m not holding my breath.

How Twitter ruined a great iPhone app

Twitter’s iPhone app started with humble roots. Loren Brichter created Tweetie, a beautifully designed and elegant client for posting to Twitter. After reaching version 2, Tweetie was acquired by Twitter. Loren Brichter joined the team and continued to develop the app.

Along the way, Twitter began to groom the app to fit with their vision. This resulted in the culling of a few features – Twitlonger support and Twitter location browsing. Twitter had experimented with advertising in the application, which eventually was dubbed the “dickbar.” Users were outraged at the addition of this bar, which contained trending topics and ads. The bar itself was pretty obtrusive and popped over top of tweets while you were reading – effectively disrupting the experience.

#dickbar

Twitter’s Quickbar, dubbed “dickbar” by users. Credit: Paul Swansen.

Twitter eventually saw the light and removed the Quickbar/Dickbar from the app, and the users were satisfied with the app once again.

Twitter released an update today, drastically changing the UI. There wasn’t much that remained the same.

Twitter’s new UI

No updated time displayed on refresh

Inconsistent search bar

Account switching buried

My complaints with the new UI are as follows:

  • Wasted space – there’s a lot of horizontal space wasted by chrome of the app, which then causes you to lose vertical space due to text-wrapping.
  • No swipe gestures – prior to 4.0, a user could swipe left or right on a given tweet to bring up controls to favorite, reply, or retweet. Those are gone in 4.0.
  • Inconsistent search – There’s no search bar on the main view, the connect view allows you to search for a given user but not tweets.
  • Account switching buried – You now have to go to “Me” and then “Switch accounts”
  • Direct messages buried under “Me”, just like account switching.
Twitter has a lot of work to do in order to make this app usable. If you’re looking for an alternative in the case Twitter doesn’t fix these issues, check out Tweetbot.