Amazon Advances Cloud Computing with the introduction of a private clould. The economics really are powerful enough to force business to take note. Anecdotally I’ve spoken to several highly functional startup web application using the clould succesfully. WIth the advent of more secure private clouds I don’t see how enterprise can stay away much longer.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=3a77e2fe-f4b4-41c6-bd01-4dcbe7aa4b91)
It’s great to get some market recognition for all our efforts. In this post Forrester recognizes that technology differentiates and our addition to Publicis will help strengthen their market position. This captured our attention
‘“What about Razorfish? The firm has much stronger design capabilities, both for user experience and what we call “brand image”. Plus – and this is just my opinion because we did not evaluate them on this – it has stronger technology capabilities as well. ‘
And validation of what we’ve been saying from the start
‘Because ultimately, a great design has to actually work in order to deliver a great customer experience.“‘
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=da3b33c6-120c-4091-acd8-c0be1bd8f56c)
In true Agile style, the Agile community is doing their 4th annual survey. Last year it sounds like they had 3000 respondents in 82 countries, pretty wild. Kind of reminds me of a sprint retrospective;).
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=d9c806d0-d0c2-4f98-b513-ae78dadaeaeb)
With the recent release of Silverlight 3 and Flash 10 / Flex 4, the Flash vs Silverlight debate has been stoked yet again. The debate has been raging on twitter using the tags #flex #silverlight. Links to articles are posted almost every day and retweeted endlessly.
The latest two most talked about articles fall squarely on each side. On the Silverlight front, a blog post from a coder with a lot of experience in .NET and some Flex experience shares his insights on enterprise development. His experience with C# colors his opinion of Flex development however, and his inexperience with Flex is evident through his omission of development tools such as FDT and Flex frameworks such as Mate. His biggest arguments revolve around language features (C# is a more robust, full featured language), AS3’s lack of a native decimal type, and the Flex IDE. In regards to Silverlight’s penetration, the author claims that since Enterprise apps work within a company, it’s easier to get Silverlight installed. He finishes the blog post with a nod towards Flex: “this particular Flex application is the best looking application I’ve ever seen!”
On the Flex side, Tim Anderson writes about the release of Morgan Stanley’s Matrix application in his blog. In it he highlights a few points made during the presentation on why Flash / Flex was chosen over Silverlight. The main points of the article highlight Flash Player 9’s penetration and Silverlight’s lack-there-of, the application’s speed, and allowing the designers on the project to use products they wanted during development. The most insightful quote of the presentation was regarding the design tools:
“You have to look at the people that use that technology. The design community. That’s the biggest problem that Microsoft has. The designers all carry around Apple laptops, they all use the Photosuite [sic] set of software tools. It’s like asking structural engineers to stop using CAD applications. That’s the tool that they use, and if you can’t convince them to switch away from your software suite you are going to get a limited number of designers that will use Microsoft’s toolset … if you can’t get the designers to switch, to learn a new language, then how can you possibly ever get some traction?”
So there you have it, one article by a seasoned .NET developer decrying Flex’s lack of language features and another decrying Silverlight’s inability to win over designers.
I have also straddled the fence between .NET and Flex developer for a number of years and have worked a little bit with Silverlight, so I tend to agree with both articles. They are both right. AS3 is an inferior language and it’s default IDE is definitely no match for VS.NET, however Flex/AS3’s speed isn’t as bad as is made out and it’s a platform that is ubiquitous and has a VERY low barrier of entry for designers and other non-developers.
So this debate boils down to form vs function. It’s harder to write a large application with a lot of business logic in Flex, however it’s easier to make it look good. The opposite is true for Silverlight. So just like a with any other technology, you have to make a choice based on your audience, the design, and the lifetime of the application.
So I’d recommend Silverlight if:
I’d recommend Flash if:
You can duplicate most sites built in Flex in Silverlight and vice-versa (with a few exceptions). It’s just a matter for the right tool or the right job. I lean towards Flex because I feel it has the most flexibility (no pun intended), but I do like XAML / WPF / Silverlight and am excited to see it evolve and be a competitor to Adobe.
Everyone wins when there is competition.
During the development of any project that involves HTML, there’s always a nagging question in the back of your mind: “How broken will this site be in IE6?” Here’s an article that will reduce the amount of worrying you do when fixing your site to work in IE6. It covers the majority of issues you’ll encounter when working with IE6.
Definitive Guide to Taming the IE6 Beast
The article covers:
It’s probably the last article on IE6 specific CSS techniques you’ll ever need to read. Required reading for all PLD’s.
On the topic of IE6 and whether or not we should still be supporting it, here are some thoughts.
IE6 support seems to be waning, but we still have plenty of clients that are still running IE6 exclusively on their work machines, so until they upgrade to Windows Vista / 7 we’ll continue to have to support them.
In the past year there have been a few campaigns to get people to upgrade like hey-IT.com, www.bringdownie6.com, and www.end6.org. Also, Google just announced that YouTube wouldn’t support IE6 anymore in the near future.
Sadly, the more I thought about just saying “no more IE6 support”, the more I realized that the people that were running IE6 at this point couldn’t upgrade. They are usually either on older machines (Windows 2000 or earlier) or their IT won’t upgrade because of a legacy web-based application depends on it, like a CRM or ERP app. These applications aren’t upgraded often, and they are definitely not upgraded during a recession.
Full IE6 support is vital for any site that caters to business users (IT issues / older computers), international users (older computers), or a large percentage of the public (lots of people don’t upgrade their computers/OS when all they do is browse the web with them).
Here’s a good chart that shows the trends for various browsers / versions from Oct-04 to May-09 based on data from NetApplications.com
It shows IE6 usage just below Firefox usage in May-09.
As much as I dislike “fixing” the sites I work on to work with IE6, I think we’re going to have to do it at an agency level for another year or so.
AIIM (www.aiim.org) non-profit organization for enterprise content management (ECM) has released a report on how “Collaboration and Enterprise 2.0” is gaining importance among business.
According to this AIIM report, there has been a dramatic increase in the understanding of how Web 2.0 technologies such as wikis, blogs, forums, and social networks can be used to improve business collaboration and knowledge sharing, with over half of organizations now considering Enterprise 2.0 to be “important” or “very important” to their business goals and success. Business take up of Enterprise 2.0 has doubled in the last year.
Here are some key findings:
About 47% companies opted for SharePoint as a collaboration platform
SharePoint is leading the Enterprise 2.0 revolution by providing a comprehensive business productivity platform that combines traditional collaboration solutions with newer social-computing technologies in an enterprise-capable product. Using rich blog, wiki, RSS, mashup and social-networking solutions combined with the enterprise content management and search capabilities of SharePoint, SharePoint customers are well positioned to deliver real Enterprise 2.0 solutions today.
Companies can use social tool plug-ins like Socialtext, Atlassian Confluence, and Connectbeam (among with many others) to add more advanced SharePoint social features.
More information about SharePoint Server social-computing is available on Microsoft’s website
You can read more SharePoint articles and how-to’s on my SharePoint blog.
As the Razorfish Guide to SXSW became more fully developed, we started to look at key areas where we could make performance gains and either actually speed up the site or simply make the site appear to load more quickly. (Check out part 1 of our story to see how requirements for the site were gathered and part 2 to learn about how the site was architected)
One of the earliest steps we took to optimize the application was to use server-side caching. ASP.NET allows you to cache just about anything on the server for quick retrieval. Taking advantage of this feature means that you can avoid extra trips to the database, requests to other services, and repeating other slow or resource-intensive operations. The Razorfish.Web library’s abstraction makes ASP.NET’s caching easy to use, and we quickly added it both to all database calls and to store most MVC models.
A second key optimization was to add GZIP compression to our assets. GZIP compression shrinks the size of most text-based files (like HTML or JSON) down to almost nothing, and makes a huge difference in the amount of time it takes for a slow mobile client to download a response. IIS7 has this feature built in, but we were running the site off of an IIS6 server. Happily, Razorfish.Web.Mvc has an action filter included that supports compressing your responses with GZIP.
Next, we used Razorfish.Web’s dynamic JavaScript and CSS compression to strip out unnecessary characters and to compact things like variable names. Minifying your scripts and stylesheets reduces their file size dramatically. One of the nice features of Razorfish.Web is that it also can combine multiple files together, reducing the overall number of requests that a client has to make. All of this happens dynamically, so you’re free to work on your files in uncompressed form, and you don’t have to worry about going out of your way to compact and combine files.
Another key optimization was combing all of the image assets into a single file, and using CSS background positioning to choose what image to display. Doing this not only cuts the number of requests that have to be made (from 10 to 1, in our case), but also cuts the overall amount of data that needs to be loaded. Each file has its own overhead, and you can cut that overhead by combining them.
As we started testing on the actual iPhone, we still weren’t satisfied with the page’s load time. There was a significant delay between the page loading and the scripts loading over the slow EDGE network. This defeated the purpose of the JSON navigation because the user was apt to click a link before the scripts had a chance to load and execute – meaning that they’d have to load a new HTML page. If the scripts were delivered in-line with the page, there would be no additional request, and they could execute right away. Because the successive content was to be loaded with JSON, concerns about caching the scripts and styles separately from the page were moot. We set about extending Razorfish.Web so that it could now insert the combined and compressed contents of script and style files directly into the page. By moving the scripts and styles in-line, we shaved off about 50% of our load time, and the scripts were now executing quickly enough that the JSON navigation mattered again.
A final touch was to take advantage of Safari Mobile’s CSS animation capabilities. The iPhone supports hardware-accelerated CSS transitions and animations, meaning fast and reliable animation for your pages. We added a yellow-glow effect to buttons when pressed. The glow was not only visually appealing, but its gradual appearance also helped to distract the user for the duration of the load time of the successive content.
The team managed to pull the web application together in time for launch, and the guide was a smashing success. Over the course of SXSW, sxsw.razorfish.com was visited by 2,806 people who spent an average of 10 minutes each on the site, typically viewed about 8 pages, and often came back for second and third visits. The site attracted a large amount of buzz on Twitter and was praised as the go-to guide for the conference.
When designing for mobile, speed is key. All of the components of the site, including the design, need to work together to connect the user to the content as quickly and as efficiently as possible. In such a hyper-focused environment, the user experience, graphic design, and technology need to be unified in supporting a shared goal.
By producing a responsive, reliable, easy-to-use, to-the-point, and locally-flavored guide to the city, the team succeeded in creating a memorable and positive impression of Razorfish at SXSW.
Believe it or not but Microsoft’s newly evolved search engine bing is nothing less than the answer of the above analogy question. You must have solved many of these analogy questions during your SAT exam. When I apply my knowledge and understanding to the question“Windows : Mac :: Google : (?)”, my answer is “bing”.
Remember when Apple release it powerful Mac OS X operating system, almost every single pundit in the industry agreed that Mac may not be the most powerful system for productivity but it is certainly the coolest and the best for creativity. Young people care more for creativity and less for productivity. Windows simply felt old and outdated. Mac operating system took off since then and market share for Mac is still increasing at a growing rate. This time bing hits a home run. After the launch of fully revamped bing search engine (or as they call it decision engine) Google search kind of feel old and out dated.
Some people say bing = “But it’s not Google”. I could not agree more. As Windows can never be Mac, bing can never be Google. In fact this time it is better for Microsoft to craft its own path and define its own destiny in search engine. The cool informational home page imageand vibrant brand colors have some kind of enigmatic charm. The creativity of bing may not appeal to mass population yet but as I know it many young kids simply love bing. They think bing aligns more with their taste.
While there are many features that make bing cool (and I will let you find out most of them yourself), I believe for me following are the best:
The list is simple but shinny. bing’s appeal to my creativity (which is not abundant) is noteworthy. I am an avid Google user but nowadays I go to bing for more than ½ of my search queries. It is fun and engaging. Google search results are still the best. So when I am searching for something very critical (items on which my job is dependent on :)) I still believe in Google but for everything else I go to bing…
– Salim Hemdani
Up against a tight deadline, our small team was working fast and furious to create the Razorfish mobile guide to Austin in time for the SXSW Interactive conference. With our technologies determined and all eyes on the iPhone, we set out to bring the guide to life. (Check out part 1 of our story to find out more about how we set requirements and chose technologies)
The guide is content-driven, and we knew that the site wouldn’t be given a second look without strong content to back it up. Our team decided on structuring the site as nesting categories with a design reminiscent of the iPhone’s Contacts application, and breadcrumb navigation (as is found in the iTunes Store).
With the flow determined, the creative director started developing the content categories and soliciting suggestions from the office about their favorite Austin haunts. She enlisted an information architect to assist with writing the site’s content, and they churned out the site’s content over the next several weeks.
Simultaneously, one of our presentation layer developers began work on graphic design, another focused on hosting and infrastructure, and I began working on database and application architecture.
The first major issue we tackled when working on the front-end of the site was navigation. We had identified several features that were essential for the guide to perform satisfactorily:
To satisfy both the first and last requirements, we were going to have to effectively have two versions of every page running in parallel (a JSON version for AJAX-ready clients and an HTML version for others). Luckily, the MVC framework makes this easy on the server. By properly defining our data model classes, we could either send the model object to a view page for each of the data points to be plugged in and rendered as HTML, or we could directly serialize the model to JSON and send it to the client. To make it easy for the client script to select the right version, all of the JSON page URLs were made identical to the HTML URLs, except with “/Ajax” pre-pended. With this URL scheme in place, JavaScript could simply intercept all hyperlinks on a page, add “/Ajax” to the location, and load a JSON version of the content instead of a whole new page.
To determine when to use JSON and when to use HTML, we did some simple capabilities testing. If window.XMLHttpRequest, the W3C standard AJAX class, exists, then it was safe to use JSON navigation on the client. Incidentally, Internet Explorer and many mobile browsers do not support this object, which greatly simplified later development.
Several JavaScript classes were created to support page rendering: A history class to manage caching and the forward/back buttons, a base page class that would take care of rendering JSON into HTML, and an application class that would manage the interactions between the pages, the history, and the user. A handful of page types were identified, and subclasses were created from the base page for each specialized layout and different data model.
A method called BrowseTo was defined on the application class that would handle all actions associated with the user clicking a link or going to a new URL. BrowseTo did several things:
Due to time constraints, we opted to use “dirty-caching” for JSON data. When dirty-caching, you’re storing the JSON object in memory under a key. In this case, the key was the URL. There are a few downsides to this method:
Because the size of the data that we were caching was very small, and dirty-caching is both very fast to implement and universally supported, we used it to temporarily story data. Given more time, we would have taken advantage of the iPhone’s HTML 5 local storage features. On any browser that supports this feature, you can store data in a database on the client. Many web applications take advantage of this feature to provide persistent offline access to content. The downside is that the HTML 5 local storage API is somewhat tricky to implement properly and is currently confined to a select few browsers.
Forward and back button support comes naturally when you’re loading new pages, but for the JSON version of the site, we implemented a solution based on URL hashes (the # data at the end of a URL). Most browsers will include URL hashes as a state that can be navigated to using the forward and back buttons. By regularly scanning the URL hash, you can update your page when there’s a change and simulate forward/back button support. Our history class was designed to add the “/Ajax” path as the URL hash, making it easy to determine what JSON data to load when the hash changed.
With our navigation system intact, and our creative team churning out new content for the site, we took a step back and started to look at performance. Check back next week, and see how we fine tuned the site to work quickly and responsively on the iPhone.
Once a year, the internet comes to visit Austin, Texas at the South by Southwest Interactive (SXSWi) conference, and, for 2009, the Razorfish Austin office was determined to leave an impression. We ended up making close to 3,000 impressions.
Industry leaders and the web avante-garde converge on Austin for one weekend each year to learn, network, and see the cutting edge of interactive experience and technology. And also to take advantage of any number of open bars. It is a conference, after all.
The Razorfish Austin office typically plays host to a networking event and takes out ad space in the conference guidebook. In 2009, confronted with shrinking budgets in the wake of the global financial crisis, we knew we had to set ourselves apart and do it on the cheap.
iPhone Apps were on everyone’s mind (and would be in every conference-attendee’s pocket), and would prove to be the perfect venue to showcase Razorfish’s skill and Austin’s personality. In late January 2009, Three presentation layer developers and a creative director formed a small team and set out to build an iPhone-ready guide to Austin.
Over this series of articles, I’ll be diving into how we created the Razorfish Guide to SXSW iPhone-optimized web site. Part 1 will deal with requirements gathering and technology choices, part 2 will cover design and development, and part 3 will talk about what we did to optimize the mobile experience.
The first thing we did as a team was to sit down and discuss what the guide had to be. Going in, we knew we wanted it to be on the iPhone because of the cachet associated with the device. We also knew that we had a very condensed timeline to work in – we needed to launch in 5-6 weeks, and we all had other projects that required our focus.
One of the first decisions we made was to approach the guide as an iPhone Web App, rather than building an Objective-C compiled application. We knew that we didn’t have a technical resource who already knew Objective-C available and that we would have trouble getting approval and into the App Store in time for our launch. Most importantly, we needed as many people as possible to be able to use the guide, and didn’t have time to create different versions for different devices.
iPhone Web Applications offer not only a way to leverage the iPhone’s impressive graphical capabilities, thanks to Safari mobile’s excellent standards and future CSS support, but also a way to reach other platforms using progressive enhancement (testing for a feature, and then enhancing the experience for clients that support that feature).
There are dozens, if not hundreds, of mobile browsers out there, with wildly differing interpretations of CSS and JavaScript. Check out Peter-Paul Koch’s CSS and JavaScript mobile compatibility tables if you need convincing. Supporting multiple mobile devices is no cakewalk, especially since many of them have incorrect or misleading user agents.
The iPhone was our target, and some mobile browsers, such as many versions of Opera Mobile, also have relatively good standards support, but what about IE Mobile or Blackberry?
We quickly came to the conclusion that, because of the condensed timeline, we should test in and support Safari Mobile only, however, that the site also needs to be fully usable with no CSS or JavaScript whatsoever. By ensuring this baseline level of functionality, we could be certain that even the Blackberry browser could at least limp across the finish line.
Along with choosing mobile browsing platforms to support, we also had to decide for which desktop browsers to design the site. Ordinarily, desktop compatibility testing is dominated by Internet Explorer 6, but this site was geared towards web designers and developers.
That means more people would be visiting the site using Chrome than would be IE6.
IE6 was swiftly kicked to the curb, and we settled on fully supporting Firefox 3, Safari 3 and Chrome, with basic support for Internet Explorer 7. Safari and Chrome support came almost for free, because the two render almost identically to iPhone’s Safari Mobile.
Supporting mobile devices supporting weak signals, slow connections, small screens, bite-sized memory, and users who are on the go. There are a number of factors conspiring against any mobile website, and we knew that we would have to eke every last bit of performance out in order to overcome them.
Client interaction with the server not only increases design complexity, but it also increases the size and number of requests. There were several key factors that made us decide to keep forms and complex interactivity out of the site:
To make the site run quickly, launch on time, and be successful in its goals, the application would be focused on being the best guide it could be, and not on integrating your Twitter account and kitchen sink.
Lastly, the guide had to make Razorfish look good and leave a strong impression of who we are and what we’re all about. If the guide was as informative and fast and easy to use as can be, but didn’t sell our brand, it would be a failure.
Based on the requirements we gathered, the team picked familiar development libraries and languages to work with.
These languages should come as no surprise, as they’re integral to all web applications. An important decision that we did make, however, was that no JavaScript or CSS frameworks should be used.
For desktop development, our industry has become increasingly reliant on JavaScript frameworks to smooth out cross-browser wrinkles and speed up our work. Generally, JavaScript frameworks excel at meeting both of those goals.
There are a couple problems when considering a JavaScript framework for mobile development:
In the future, JavaScript frameworks may overcome these challenges, but we resigned ourselves to starting from scratch for this project.
CSS frameworks were out of the question for many of the same reasons.
The ASP.NET MVC Framework was chosen as our server-side technology primarily because of the team’s familiarity with it. Having just recently used the technology on other projects, it was still fresh in our minds. The MVC framework allows for quick, clean and very functional design that you have a great deal of control over.
We elected to use our internally-developed .NET library that’s specialized for use on web projects. Razorfish.Web has a number of features that made it indispensible for this project, such as dynamic CSS and JavaScript compression. As I’ll cover later, we extended the library while building the guide to push optimization even further.
Microsoft’s database engine was the natural choice to go along with ASP.NET MVC. We used LINQ to SQL to easily communicate with the database from the web server.
With our tools selected, we were ready to start building the site. Come back for part 2 to learn about some key design and development decisions that went into making sxsw.razorfish.com.
