Search is one of those things that seems simple but is difficult to do well. The most common problem users tend to face when searching is that either no results are returned, or there are too many irrelevant results.
On a recent project we had the case of a simple keyword search bar that not only had to return relevant results but aggregate data returned from several sources. The user expects to type a search and get nicely-formatted results that match their query. Our problem was that the results came in multiple formats from multiple servers with quite variable response times.
Our initial implementation was to have tabs. The Addresses search was run, results were shown, and the other inactive tabs when clicked would carry out their respective searches. The problem was that there was no guarantee the first search type (addresses in this case) would return any results, and if the businesses search had returned results it would have been much better to display that first. The tabbed interface was also very disjointed, as swapping tabs had to perform the search (causing a delay), and users expect switching tabs to be instant. Also, the usability suffered, because if the search resulted in a few matches of each type, you couldn’t see them all on one screen.
The final implementation was in two parts. Firstly, all the searches were executed in parallel via Ajax, displaying and updating a progress bar as each was completed. This visual feedback helped offset the now-longer delay before any results were displayed. Then the data returned from each API was normalized so it could be fed to a single HTML render, facilitating output into the same screen. This allows the results to be displayed in a single list, grouped by type. Types with no results (or ones that timed out) are omitted from the output, pushing the relevant results to the top.
We've worked on a number of multilingual sites over the last few years, each coming with its own set of challenges. Often it's easy to underestimate the extra amount of work an additional language will add. Design is the main area that needs to be considered, but it's also important not to forget about messaging and quality assurance.
Design needs to take into account the different amount of space each language will need to say the same thing. Problem areas include menus, dialogs and buttons. For example, on any given button, the text in French will be four times wider than in Chinese; this means that not only will the button have to be wider, but its container also needs to be able to accommodate the extra length.
There are roughly four main language groups:
If the design requires copy to fit tightly, then a separate layout for each language or language group is the best option. The alternative is a design with built-in flexibility to handle variations in content width. Designing for the longest language, and allowing for the layout to contract if necessary, tends to be the best plan of attack. Trying to build a design that works for all languages, unless it's very simple, generally ends up with a poor visual result.
Messaging is easy to overlook, but there are a lot of places where error messages can be generated. There's the front-end in form validation and the back-end in Ajax responses; all the possible error, confirmation and status messages need to be translated. In addition, Quality Assurance needs to test every combination in every language – and if several languages are involved, the amount of work can really add up.
Multilingual sites can be straightforward if they've been well planned, but it's never a case of just dropping in replacement copy over the English text!
We're a big fan of using the latest APIs and pushing browser-based technologies to their limits. A recent project required complex Google Maps implementation, so the new version 3 API was the obvious choice. It's many times faster than the previous version, has location services, and works well on mobile devices (like the iPhone). The project's mapping functionality proved to be a success; however, it wasn't without a few technical challenges along the way.
One of the problems with adopting new API's is that the eco-system of code that interacts and extends it is often very immature as well. Code examples can also be a little sparse, though fortunately Google's documentation was excellent in this regard. The difficulty is when you need something that's not included in the box. Our map has markers, a lot of markers, thousands of them in fact, and to stop the browser impaling itself on a spike we needed marker clustering.
Clustering is where you replace several individual markers with a single marker group icon that indicates to the user that there is X number of markers in this location. The more you zoom out, the greater the number of markers grouped into each cluster. The clustering solutions for Google Maps version 2 were numerous, but for version 3 there was just a handful. The most suitable library was barely 3 weeks old, certainly immature, but as a port of a stable release of the same library for the v2 API it was a viable option.
Another problem we faced was that the styling provided by the library was limited. It expected the marker to be centered on the location, rather than above the location as the design needed. Method overrides and a good understanding of cross-browser rendering bugs allowed us to extend the library to meet our – and our client's – needs.
Creative agencies such as advertising and design firms must deliver high-quality sites and apps on aggressive schedules for big brand clients. Unfortunately, agency teams often have limited technical expertise and few engineering resources. Agencies are driven by creative. They have amazing creative, art, and design teams. However, they seldom have deep technology experience and they often lack depth in software development. Driven primarily by creative marketing people, agencies seldom have creative technologists on staff and they struggle with technical documentation, process, and software development discipline.
This is why Fabric are the preferred development partner for agencies when they need to deliver social sites and apps for major brands. We add layers of expertise, skills, and proven execution ability to agencies in need. We've done it for Carmichael Lynch, David & Goliath, and even for interactive agencies such as Rocket XL.
We help agencies with technical expertise, writing functional specifications and UX documentation. We offer integrated development teams and our battle-tested process to deliver large scale social sites, complex API integrations and data aggregation solutions. Custom CMS builds or complete transition or integration of CMS solutions such as Silverstripe, Wordpress, and OneSite.
But most of all, the main reasons agencies hire Fabric is to make sure that important projects are delivered with top quality, on-time, and on-budget. Agencies smile. Clients are happy. That's what you want, right?
Technology and Sephora are two things I love. News about Sephora “doubling down” on tech intrigued me. They've revamped their site with a new look, more features, and “Pin it” buttons on their product pages; updated their mobile web and iOS apps; and planned to roll out iPads in some of their stores this year.
While Fabric works mainly with start-ups, it never hurts to take a tip from the big guys.
The first item I want to note is Sephora's site brought up a page over the homepage that describes the changes:
The world's favorite social networking site is infamous for rolling out changes unexpectedly and there is almost always an immediate backlash. I attribute this to the lack of warning in the early days (now, Facebook is a lot better with guides and tips on how to use new features). As someone who works behind the scenes on web sites, I know how much we in the industry rely on users to just “get it.” We say that the changes are better and more user friendly so everything will explain itself. I encourage everyone to take a look at Sephora's approach in first outlining the main changes, and then guiding the users to the new features and pages:
Lastly, I'd like to point out the reason for the increase in technological integration: according to Mashable, Sephora has seen an increase in mobile shopping at its web site, namely from iOS devices. Take time to learn about your customers, and you'll have, at the least, a starting point for reaching them.
You are currently browsing the archives for the Development category.