This was a compelling idea to me, having spent the previous nine months working on a large-scale Symfony project. As a new employee at NavArts, I couldn’t believe that two of my favorite frameworks were going to be ‘merged’ in a way I had never fathomed. I immediately altered my penciled-in schedule so I could attend the ‘Drupal 8 Meets Symfony2‘ presentation given by Fabien Potencier, the Symfony founder and lead developer, and Lukas Kahwe Smith, a Symfony2 core contributor and PHP 5.3 Release Manager.

Below is a brief synopsis of the presentation along with some research materials:

Drupal 7 was the first release that had any type of object oriented (OO) methodologies and OO design patterns. Other PHP frameworks and CMS applications have been built using these practices for years. As many Drupal developers know, there is one way to do something and there is the “Drupal Way”. Unfortunately this is because not enough change has been implemented in Drupal 7 to affect its internal structure to be like the majority of other similarly available applications. Lukas Smith,  stated “This doesn’t mean that Drupal is wrong”, but it does make it more difficult for experienced developers and juniors alike to easily comprehend and master Drupal. It has become so complex that only those who have been using the application and participating in its evolution can really grasp the core of Drupal itself. As these developers leave the community or move on, it will become increasingly more difficult to replace them with people who have the same amount of historical knowledge.

So, Dries and other core contributors held a sprint for the Web Services and Context Core Initiative (WSCCI) for Drupal 8 in early February to discuss the future of Drupal.The preliminary goals of the sprint were clearly defining the initiative’s scope, get agreement on what was to be accomplished and why, as well as laying out a clear plan for how this was going to be achieved. Although there were many discussions and other improvements made to the core, one of the most exciting was the adoption of a handful of Symfony’s components.

For those of you not familiar with Symfony or what it provides, it is a reusable set of standalone, decoupled, and cohesive PHP components that solve common web development problems. Symfony is a full stack web-framework with an Object-Oriented set of classes compatible with PHP 5.3 and later. So, you have Drupal which is an infinitely extensible Content Management System and Symfony, a Content Management Framework. The components being adopted by Drupal are not minor components from Symfony or for Drupal, but major components that will provide the base for a great low-level architecture for Drupal 8. These components are HttpFoundation, HttpKernel, Routing, EventDispatcher, DependencyInjection, and ClassLoader.

By adopting these components from Symfony it will facilitate the refactoring towards a “framework” core for Drupal,  also allowing for easier integration with other applications and best of all, by bringing the communities of Symfony and Drupal together it will ensure that the Drupal developer pool will continue to grow and persist, rather than falter as a result of attrition.

I provided links from the Symfony website for the components discussed above. You may also find more information from the following sites:

• Official Symfony website – http://symfony.com
• Symfony Repository – https://github.com/symfony/symfony
• Symfony Components – http://symfony.com/components
• Components Repository – https://github.com/symfony/(component name here)
• Dries Buytaert’s blog entry discussing the Symfony2 decision – http://www.buytaert.net/the-future-is-a-restful-drupal
• Fabien Potencier’s entry discussing Drupal 8 and Symfony2 – http://symfony.com/blog/symfony2-meets-drupal-8

I learned early on in my career that the long-term success of the site can be dependent on how the site is managed. If making an update is cumbersome, difficult, or costly, it’s not going to be used to its full potential.

This is why I’m excited by a new push by NavArts to encourage Information Architects to broaden their technical understanding by taking CMS classes specifically geared to IAs.  The training helped us gain a deeper understanding of how the sites we design are built and managed. We concentrated on how to optimize our designs for long term content management by designing for modularized reusable content elements and how to automate the flow of content throughout the site.  Learning the nitty-gritty on how a site is built, updated, and managed through the CMS gives us the insight we need to take our designs to the next level—leveraging the inherent strengths of various CMS systems and architecting the backend-end to be as intuitive as possible for our content managers.

It was with this in mind that I recently read some of the commentary on Google’s change to its privacy policy. I still remember when Google first arrived. It was different in so many ways. At the time, Yahoo was king but I was a big user of AltaVista. You see, Yahoo was too invasive. A search on Yahoo was more like a catalogue search, and the web was changing too fast for the catalogue to keep up. AltaVista offered up a raw search interface that promised more objectivity, more control. It was a heady promise, and very addicting, but it was still not quite true. I felt  there was a fudge factor behind the scenes, and the results were not always dependable.

Then along came Google. From the moment I first used Google, I knew this was something different, something more honest and true. The spare interface shouted, “Nothing but results!” Behind the spare interface the search engine was also different. Somehow the results returned seemed more accurate. The first time I entered a search that returned zero results, I was hooked on Google. No other search engine had ever been so honest as to openly say that what I was searching on was ridiculous, and when Google did, I knew that I was getting an honest result.

However, even before the controversy concerning Google’s privacy policy, I had begun to wonder about the accuracy and honesty of Google search results. It started simply enough. In my non-existent spare time, I am renovating my house and shopping for a door. Wrestling with the build or buy decision, I visited an exotic lumber retailer nearby and used my phone to perform a search that I had performed many times before at home. But the results on my phone were completely different.

That forced me to start really thinking about my trust in Google. How could the results be so different? The answer was simple: Google was using information from my browser at home that it no longer could access on my phone. Ah. Tracking cookies. On the one hand, I missed the repeatability of the search I had performed at home. Yet, on the other, I realized that all my searches had been limited. Could the door I really wanted have been just around the corner, hidden by Google’s opinion of me?

Having first noticed the skewed search results, I then began looking for more evidence of the Big Brother effect.  We recently launched a new website for Breitbart. As part of the launch, we performed research on various ad solutions. That led me to really look at the ads being served to me. And yep, they were doing it again. The ads were definitely targeting me. When I was in Los Angeles helping with the launch  I was receiving ads for the LA Galaxy (they should be careful since I am an avid DC United Fan), and, now, back in DC, I’m getting ads for the Shakespeare Theatre Company.

I want my control back. I want an easy way to say stop or go. Do I want it enough to move to one of the Google alternatives? I’m not sure yet, but I can tell you I’m shopping around. And you know what? I’m starting to feel a little more creative.

After writing this article I happened to catch Dan Russell, basically the “Director of User Happiness” for Google, on the Kojo Nnamdi show. The interview is a good exploration of Google’s perspective on search and their new privacy policy.  Definitely worth a listen.

The goal was to increase usage of the site, increase leasing, and of course provide clearer pathways for residents to use their existing tools (like the Resident portal).  According to an article in The MultiFamily Executive the mark was hit and then some:

 ”MAA unveiled its new site last March and, so far, it’s working well, Ogle says. Twenty percent of applicants are now leasing online, and, she notes, ‘We’ve seen a 17 percent increase in the number of resident portal sign-ups since launching our new website. Currently, 70 percent of our residents have an active myMAA.com log-in account, and 34 percent pay their monthly rent online, compared with 24 percent the month before we launched the new website.’”

This was accomplished through the careful implementation and integration of multiple back-end systems: leasing, real-time pricing and availability, analytics, and of course a well crafted User Experience for both the desktop and mobile user.

A key factor to note is the number of non-technical staff that manage and run the 160+ websites: only 2.  This is an example of a Technology Experience commensurate with its sibling – User Experience.  Unfortunately many organizations are slow to recognize the ROI achieved by building fully integrated systems that are as easy to manage as this one.

User Experience coupled with an equally thoughtful Technology Experience provides direct and immediate results.

I’ve noticed a phenomenon over the last year or two that is not necessarily a good thing:  older hardware that can’t handle the latest software update.  It started with my old Droid Eris cell phone.  When I first got the Eris it was a smaller, cheaper alternative to the larger Android phone.  It ran version 1.5 of the Android OS and didn’t have some of the cool features of the larger phone, like turn by turn GPS navigation, but it worked well enough.  The user experience was pretty good and the phone was responsive and easy to use.

About 5 months after I got the phone Verizon announced that they were going to be releasing a mandatory upgrade of the OS that would get automatically pushed to all Droid Eris phones.  They were upgrading to version 2.1 of the Android OS and this would include all the cool, fancy features of the new OS!  The upgrade went fine but it didn’t take long for me to realize that the hardware of the Eris just couldn’t handle the complexities of the new OS.  The phone was much, much slower.  The GPS and navigation features were very cool but frustratingly slow at times.  Apps were crashing much more than before.  In general the phone was much less stable than before and the user experience was terrible.

I’ve also noticed that this is not just a problem with Android products.  I’ve owned an iPad now for almost 18 months.  Originally, it was shipped with v4.3 of the iOS.  It was great – very snappy and responsive and almost never crashed.  Last fall Apple released v5 of the iOS and made it available for the iPad.  While it wasn’t mandatory to upgrade, it certainly seemed like there were a lot of features that would make using the iPad a better experience and Apple was certainly not warning owners of the original iPad not to upgrade.  Yet my experience has once again been that the hardware of the original iPad just can’t keep up with the demands of the new OS.  I have found that some of the main apps like Safari and Email are significantly less responsive and the entire OS in general is more sluggish.  I’m also finding that apps crash much more frequently than before.

As a self-professed computer geek and early adopter of new technology, I am usually clamoring for the next release of a product or the latest updates.  When I read about some new whiz bang feature I want to get it right away.  I think that in the future I will be much more wary about automatically upgrading software on my electronic devices – especially full blown upgrades of the most important piece of software – the operating system.  I’ve found in my own experiences that sometimes the awesome user experience of an older OS (with fewer cool features) is better than the terrible user experience of the latest OS on inferior hardware.

Spotify has been actively chronicled in the U.S. since its July 2011 launch, yet I still run into people who have no idea what it is. (That same weekend, I was at my brilliant yet unwaveringly anti-social media brother’s apartment, listening to him stream music through his tired iTunes account. Ugh.) For those like my brother, a Spotify cheat sheet:

• Digital licensed music streaming service – all major record labels and some independent
• Artists earn royalties whenever their music is played – a platform for the anti-pirates
• Popular in Europe (HQ Sweden) for years, but only hit the U.S. 7 months ago
• NOT based on an algorithm (like Pandora) – you choose exactly what you want to listen to
• Extremely limited free version (lots of ads, no mobile option), as well as monthly Unlimited ($4.99) and Premium ($9.99) versions – basically, you should go Premium
• This past fall integrated with facebook, meaning that all new users must have a facebook account if they want access to Spotify
• Optimized for Windows, Mac, Linux, and mobile – iPhone, Android, Windows, Symbian, (Palm – Europe)

To me, Spotify represents two game-changing elements: mass digital socialization of music, and real user experience driving a music streaming platform.

Spotify UX

The Spotify user interface screams Scandinavian design: streamlined, functional, attractive. From his blog, the lead Spotify designer describes his approach as “semi-conservative-but-still-daring in certain elements.” I see what he means: handcrafted pixels make the UI awesomely responsive. A dynamic UI personalizes features and recommendations. Common options (Starred, What’s New, Add Playlist) are clearly displayed. Options for more advanced search and tagging functionality exist but are intelligently suppressed to avoid confusion for the majority of users. Really, the UI makes a mockery of Pandora’s cluttered design and iTunes antiquated, boring, sometimes (enough with the updates) confusing layout. There’s something edgy about the dark gray color and tiny white font.

I’m always amazed by Spotify’s functionality. When there’s an action I want to take, I always think, “No, there’s no way they thought of that.” But they have. I can make playlists, and publish or hide them as I choose. I can “Subscribe” to friends, friends of friends, and totally random users, and get updates when they publish new playlists. I can send tracks to friends with written messages that are read through their facebook accounts. That’s a really amazing element: the absolutely seamless experience between facebook and Spotify. There was a ton of backlash in the U.S. when the move to integrate the two platforms happened this past fall. But I agree with co-founder Daniel Ek’s reasoning: one less user name and password to remember. Plus, Spotify users are more social.

My friends and I have found some functionality limitations. For example, you can Star an individual song or whole album (this automatically adds the tracks to your Starred playlist), but you can’t drag and scroll to Star. Also, if you Unstar a song, it just disappears, meaning that there’s no way to keep it in that folder and just not have it play. Aside from that, the dragging functionality is terrific. There are clickability features I would appreciate (album covers, for example), but it’s not so agitating to be bothersome because other pathways to get what I want are perfectly intuitive.

Spotify Socialization

The Spotify social experience is unlike anything I’ve encountered before. Prior to Spotify, my friends and I shared music sparingly – YouTube links, shared iTunes or SoundCloud account access, random music sites and blogs – but never with such ubiquity or excitement (or insecurity).  Excitement, because I love learning about my friends and their vacillating moods as I watch the real-time track ticker switch from The Allman Brothers to David Guetta. Insecurity, because failing to make a session Private (meaning no one can see what you’re listening to), can result in major social backlash when you’re nabbed rocking out to the Britney Spears-Skrillex remix. Four times in a row. But really, sharing tracks on Spotify has become an integral part of my daily routine. Never have I had such vast access to music. And never have I been OK with paying for it. In fact, Spotify might be the first music platform my friends and I have ever willingly paid for. Of course, this was Spotify’s plan all along: get users hooked, then ask them to pay for music.

Beyond sharing with current friends, I’m more eager than I’ve ever been to connect with people I think might have good taste in music. That kid from high school who was always locked into massive Bose headphones while the rest of us were trading Savage Garden CDs? Yea, I think I will find and friend him on facebook. I think it’s fair to say that Spotify is widening people’s social circles. The other day, my friend posted this facebook status: I hope you know I’m only friending you so I can see your Spotify collection.

Listening Limitations

If you’re an “I heard that track 3 months ago” type of person, Spotify might not be the best choice for you. One of the major complaints I hear from my most progressive friends is that Spotify doesn’t have any underground or collaborative music. It’s true that Spotify won’t have your local corner band’s mix tape, or that cool mashup you heard in some random warehouse. But, that’s really what niche music blogs are for. Spotify’s mission isn’t to support local artists, but rather to proliferate mass music sharing amongst friends and, by proxy, even further extend facebook’s role in our lives.

What I think is coming next – and what I can’t wait to see – are companies joining Spotify. The idea of curating playlists for branding effects and sharing them on facebook? Now, that’s an idea. After all, music moves people.

A: I come from the school of thought that minimalism, while capitalizing on open space and fluidity, does not pair well with the heavy informatics of ecommerce design. That being said, the greatest design – i.e. form meets function – occurs under a project’s constraints. It’s the out of box thinking that takes the cake.

Q: How do you feel about giant banner ads? Are they affective?

A: My thoughts on banner-ads, giant or otherwise, rank right up there with white noise. I know it’s there and so therefore automatically disregard the “noise” to scan for the information I need. Slapping an interruptive banner ad on top of a website is the equivalent of cutting to commercial on television—it’s an opportunity to go to the bathroom.

Q: It’s all about increasing conversions. Have you found any visual cues that really work in moving visitors through the buying process?

A: This is an interesting question. There are certainly cues to help consumers move through the buying process, but I’ve found that it’s a user’s ability to backtrack that tends to add the most value. We’ve all gotten lost in big online shopping sites. It’s going to happen. How you’re able to navigate back once it occurs – that’s what has the greatest impact.

Q: How important are customer reviews for ecommerce sites? What do you think about when incorporating them into the design?

A: Reviews are HUGE. They allow for a non-biased customer to rate and review. They act as one of the most cost effective selling techniques ecommerce sites have at their disposal. Because of this, I automaticcally incorporate an option to rate, review, and display popularity of any given product. The main drawback when it comes to reviews rests with authentication. There should always be measures in place so that a product’s reviewer is legit.

Q: Have you found that vertical or horizontal displays work more effectively for certain products?

A: With the advent of the tablet, I think design for responsive displays is the new standard. Any given design should be easily read vertically or horizontally with a clearly defined brand, message, and contact.

Q: Is there something you particularly enjoy about designing for ecommerce sites that you don’t get out of designing for traditional marketing sites?

A: I’m drawn to the ever-changing landscape of ecommerce. Load speed, bounce rate, conversion performance, OH MY! With a well designed site, these factors all combine to convey an informative, easily navigable site.

Her comments have waxed as I’ve gotten older and discovered – through some clandestine sifting through cardboard boxes – that not only did she have cool clothes I can wear now, she listened to music I’m into, and read books whose titles have floated around in recent conversations amongst friends. After I swallowed the whole idea that nothing I do will ever be original, I took a step back and started thinking about trends and fads. What’s classic? What’s destined to come back? What should never come back? And where does the relatively new genre of internet memes fit in?

Explaining trends is slightly less exhausting than the obtuse world of fads. Basically, trends have staying power and the ability to become a long-term influence in society as a whole. A great example of a current trend is the Occupy Protests, which have encapsulated festering class conflicts that existed long before the dawn of Twitter. Trends generally have a foothold in society before they become popularized and user adoption/acceptance spikes. Waning support for the death penalty. Digitization of Higher Ed. Working remotely. More women without children. These are all strong examples of trends.

Fads, on the other hand, are a different, incredibly fascinating, relatively understudied social and economic phenomenon. In her paper “When a Fad Ends: An Agent-Based Model of Imitative Behavior,” Margo Bergman defines a fad as an instance of “seemingly irrational imitative behavior…a drastic swing in mass behavior without obvious external stimuli.” Most theories that attempt to explain fads – network externalities (think proliferation of telephones), planned obsolescence (Apple does this all time), and information cascades (this Pez Dispenser isn’t “useful” anymore), fail to account for the rapid adoption and/or rapid exit of a product, or make inconclusive arguments around the perceived value of that product. Basically, fads can’t be explained by normal demand patterns.

In her study, Bergman used computer-generated agents to emulate real world market decisions. She called the agents “Fad Setters” and “Fad Followers” and programmed them to make fad-type purchase decisions.  She defined the Fad Setters as possessing qualities – popularity, wealth, status – that followers want to emulate.  Fad Setters are the people who begin the fad cycle. Fad Followers are also interested in new goods, but either don’t know how to find them, or aren’t interested in them until others have them.

Bergman’s agent model revealed one very important fact: if user adoption amongst Fad Setters is too low initially, the good will NOT become a fad.  This group is absolutely essential to popularizing an otherwise inconsequential idea or product.

Just for fun, lest we ever forget: The Pet Rock. Fallout shelters. Leg warmers. Bell bottoms (with a regretful resurgence in the 90s). Lava lamps. Have a Nice Day. Telephone booth stuffing (arguably a classic). Water beds. Beatniks. Beanie Babies. Yo-yos. Pogs. Zoot Suits.  And the list goes on.

So, where does the internet meme fit into all of this? Part of it has to do with time. Take a look at these graphs from Bergman’s agent model study and observe the timeline she used for evaluating the Rubik’s Cube fad.

This isn’t the point of Bergman’s study, but it’s an excellent consequence for my purposes: she highlights that, classically, fads have a lifetime of 1-3 years. The hula hoop lasted a little longer; UFO pants a little less. But this timeframe is oft cited when referring to fads.

Now this is where things get interesting: On December 21^st, I saw a youtube video (posted through a blog I read) called “Stuff Girls Say.” At that time, the video had around 2,000 views, which allowed me to do something very rare: share it with my network of friends who hadn’t seen it. If you don’t live in this hyper-networked world, then just trust me: this is a rarity.

Two weeks ago, I checked the video again. It had 8 million views. I checked again today, and it had just over 13 million views.  Seems like it’s still growing in popularity, right? Well, it’s not.

In fact right now, this video is at the declining end of its maturity. Most of the meme followers have caught on already, spurring dozens upon dozens of spin-offs: “Stuff New Yorkers Say,” “Stuff People in DC Say,” “Stuff Yogis Say,” and the list goes on. These copy cats flooded my newsfeeds for 2 weeks straight, effectively making it really not cool anymore.  And just like that, after only a month of wild success and popularity, the meme is dying.

This is the course of all memes – Double Rainbow, Honey Badger, “Planking,” whatever – to surge exponentially, quickly lose popularity, but hopefully retain some residual value.

So, it seems a meme is just like a fad, but shorter. Look at the general characteristics of fads:

Characteristics of fads (descriptive):

1. Homogenous
2. Novel
3. Odd

Characteristics of fads (user adoption):

1. Sudden
2. Rapidly Spread
3. Quickly Accepted
4. Short Lived

But there’s something different about memes: they aren’t dependent on those classic Fad Setter characteristics. What they’re really dependent on is the characteristics of the community promoting the meme.  In most cases, the meme begins with someone anonymous, and is popularized through social circles comprised of varying individuals.

Today, people can still remember sleeping in water beds, or staring at a lava lamp until 5 in the morning. Those physical fads gave us discrete memories.

But in 20 years, will I remember this meme? Likely, no. What I will remember is the communal experience of sharing these blogs, videos, photos, etc, with friends and enjoying that feeling of mutual experience.

As memes continue to pop up, I think we’ll notice a lot less concentration on fads, as what’s “cool” becomes less dependent on the perceived Fad Setter class and more reliant on what your online social circle shares with you. Memes live and die so quickly, feeding our frenzied need for constantly new content. I really don’t think we have the attention span for fads anymore.

Memes are slowly replacing fads. Memes are the trend.

“Advance, and never halt, for advancing is perfection.”

-Khalil Gibran

Time, budget, and competing business priorities make it challenging to factor usability testing into project plans. Sometimes getting a product to market quickly is the “right” business priority for the client. With agile development projects, we add another obstacle to usability testing: release quick and release often. How does a user advocate fit into rapid release cycles that often focus on complex technical fixes?

First, before development begins, hopefully the team has conducted foundational user research to root out any false assumptions or deeper problems on the design and development path. Once the ball starts rolling on rapid releases, it will be difficult to uncover any major issues.

Iterative usability methodologies are a starting point for usability testing on agile development projects. For example, Microsoft’s Rapid Iterative Testing and Evaluation (RITE) Method and usability guru Jakob Neilson’s discount usability are good places to start.  Both of these methods share similar features:

• Focus on qualitative not quantitative results. Small test groups of 3-5 users are enough to reveal most errors.
• Use simple prototypes and scenarios. Use paper prototypes to test simple use cases. Focus on ten usability heuristics instead of complex interaction designs.
• Keep the sessions simple. Having a note taker present is enough. No need for the expense and added time of video recordings.

Fitting usability into an agile development process requires a mindset change. Recognizing the truth of Voltaire’s observation that “the best is the enemy of the good,” keep usability moving forward by:

• Using the users you have.  Informal tests using the team on its own project make scheduling work easier. Remember, an imperfect methodology can be worthwhile if it uncovers problems and results in timely improvements.
• Simplify requirements documentation.  Frequent conversations with the development team and low-fidelity prototypes replace more formal requirements documentation.
• Parallel tracks for user experience and development. Let user experience work continue ahead on a separate track while complex back-end fixes are implemented.

A user experience professional bridges the gap between various stakeholders, technical requirements and user needs. As a project owner, user experience is the force that can herd the cats and focus priorities on user acceptance and adoption – the final determination of project success. Making usability a part of agile development requires a change in mindset, but leaving usability out of agile development is too costly to be worthwhile.

Do you have experience integrating user experience into an agile development project? How did it go for your project team? Please share a comment.

Sitecore employs a number of caches to improve base performance in the system.  Some contain database items, others contain access information.  One of the most important from a development perspective is the HTML Cache, which (unless explicitly turned off) exists independently.

Sitecore allows developers to place both .NET sublayouts and XSL renderings in Sitecore’s caches to improve performance.  This can be done by setting the sublayout or rendering to Cacheable=”true” in statically assigned calls, or checking the “Cacheable” property in the Layout designer for controls added dynamically through the Sitecore interface.  When a control is set to be cacheable and has been recently accessed, it is served by HTML cache designated for the current context site of the user – typically the site named “website” in a stock Sitecore installation’s production environment.

Enabling caching without setting individual VaryBy parameters caches a particular rendering’s output once for the lifetime of that cache – useful in the case of something like header text that never deviates anywhere it is shown on a site.  The HTML cache’s lifetime is dependent on several factors.  Since it lives in memory with the w3p.exe process, any time that process is restarted or killed, the cache is cleared: an IIS restart, a moved DLL, a web.config change, etc.  Additionally, the HTML cache is selectively cleared by publication events, flushing out items that may have been affected by the publication.

VaryBy Parameters

Applying individual VaryBy parameters sets aside a separate copy of the rendering’s output based on the parameters when the page is hit under those conditions.  The possible VaryBy parameters are:

• VaryByData
• VaryByDevice
• VaryByLogin
• VaryByParm
• VaryByQueryString
• VaryByUser

The parameters’ exact nature is described in Sitecore’s Presentation Component Reference guide.  It is important to understand the differences between each of the VaryBy conditions – it is easy to confuse something like VaryByLogin with VaryByUser, a very different parameter.

How does this variance work? As an example, if an anonymous user hits a page with a sublayout which is set to Cacheable and VaryByLogin, Sitecore stores a copy of the non-logged in version of the sublayout in the HTML cache, serving it up as cached HTML to any other anonymous users.  When a logged-in user hits the page, and not until then, Sitecore caches up a “logged in” copy of the sublayout’s HTML and serves that up to further users.

The idea that Sitecore only caches individual VaryBy versions after the page is hit under those particular circumstances might seem obvious, but the consequences often are not.  A major goal of caching is to reduce the times code has to be run.  When a sublayout is varied by login, there are a maximum of two possible times the underlying code will be hit: logged-in, and not logged-in.  If that sublayout requires varying by user, the number of possible times that code might be hit may be in the thousands, or millions, depending on the number of users.  Since the sublayout is not placed into cache until the condition is met – generally a good thing, since otherwise a cache could contain gigabytes of nigh unusable data – each individual user is going to get an uncached version the first time they hit that component.  If that component is very slow, subsequent actions by that user might be faster, but that first hit will always take place, where it is likely that someone else would have hit a sublayout that is only cached by login.

Below are some practical values for the number of variations a VaryBy parameter might result in, and therefore their rough effectiveness.  Note that each VaryBy has a de facto minimum of two, because otherwise there is no need to vary by that condition – if there is only one device on a website, there’s no point in varying by it.

• VaryByLogin (two variations, always)
• VaryByDevice (two to ten, accommodating various mobile or XML versions)
• VaryByQueryString (two to millions, depending on how many unique querystrings might be applied to the sublayout)
• VaryByData(dozens to hundreds of thousands, depending on how many content items are associated with that sublayout)
• VaryByUser(dozens to millions, depending on number of user accounts)
• VaryByParm(two to unlimited, depending how many parameters are used and their values)

The inclusion of additional VaryBy parameters multiplies the number of potential cacheable bits, and tends to drastically reduce the effectiveness of caching.  A homepage sublayout which has three rendering options – normal website, mobile website and RSS feed (VaryByDevice), and different content depending on whether a user is authenticated or not (VaryByLogin) will have six variations (3 device * 2 login variations).  For a busy site, this is likely a good trade-off.  A sublayout that shows a breadcrumb trail for the current page in a thousand page site (VaryByData), and filters out any pages one of the site’s ten thousand users doesn’t have access to (VaryByUser) will have ten million variations — a configuration of no practical benefit and, at the least, be likely to waste valuable cache space.

Application of VaryBy Conditions

As mentioned previously, VaryBy conditions should be applied in <sc:sublayout> calls when the sublayout is statically included in a larger sublayout or layout, or dynamically applied in the design view when the sublayouts are attached to placeholders.  Do not put VaryBy conditions on placeholders, but on the controls within them.  Placeholders are designed so modular controls can be slotted onto them, and the individual controls should be in charge of whether they are cached and under which circumstances based on their code.

Remember that caching a control automatically caches the underlying controls included in it, statically or through placeholders.  A developer cannot “uncache” a particular subcontrol that is part of a larger cached structure.  To accommodate such a scenario, follow the Divide and Conquer approach described below.

Divide and Conquer

“Divide and conquer” refers to the act of splitting functionally similar controls into separate sublayouts strictly for the purpose of dividing cacheable “pieces” of functionality from non-cacheable.  It often goes against logical ideas of what should be included within a single atomic control.  For instance, a footer often does not contain a great deal of complex logic and a developer might structurally conceive of it as a single sublayout.  Indeed, many developers are wary of creating too many sublayouts because of the implied performance overhead, so even if it logically can be broken up into separate nested controls, they would choose a single sublayout.  This is typically a miscalculation when the potential to increase caching exists.

In the footer above, the left side is utility navigation, dynamically controlled by content authors in the system.  Because there is no roll-over state on the links and is consistent across the site, it could be cached without VaryBy deviation, which allows that navigation to be an ideal compromise between content author control and top performance by hard-coding those links.  The right side contains several bits of functionality, including ShareThis links, a print friendly option, a language selector, and a font size manipulator.  All of that functionality is accomplished with identical, cacheable HTML and Javascript – except for the language selector, which is an interactive postback control, which is generally not eligible for caching (see Interactive Controls, below).  Because of that one postback control, a single footer sublayout which contains all this suddenly goes from being entirely cacheable – Sitecore generates it once on the first hit, and then it is served up from memory every time after – to having no potential for caching whatsoever unless it is broken up in smaller sublayouts, which are cached with individual VaryBy criteria.

“Divide and conquer” indicates that the footer should be broken up into smaller sublayouts, because over the lifetime of a site, there is usually nothing that gets hit more frequently than headers and footers, and even small performance savings are replicated hundreds of thousands of times over, resulting in high ROI for low LOE.  In the footer example, it makes sense to nest.

An optimized footer with nested sublayouts. 

Most comparisons should be able to easily show that the resulting gains are many times any anticipated overhead from splitting up sublayouts when there is a reason to do so.  Like all optimization exercises, it is important to do before-and-after metrics to make this demonstrable.

As a final note, this “divide and conquer” approach is a compelling reason to engage in optimization early on in the SDLC, so wireframe and control design account for performance in the componentization of functionality.

Interactive Controls

A control that posts back to the server is almost never a candidate for caching by VaryBy properties, as it varies by the form data that is posted back (not one of the standard VaryBy parameters), and often takes significant action based on that, rather than being just HTML display.  In some cases, it may be appropriate to consider rewriting logic so that a control does not require a postback at all.  A good example of this is a logout button which kills a user’s authenticated session and redirects them to a login page.  A programmer might naturally use a TextButton or other control that runs the code to log a user out on a postback submit.  But if this logout button is part of a complex sublayout that does “heavy lifting”, such as producing dynamic navigation, then that technique disallows Sitecore caching of the entire sublayout.

A more optimizable route is to create the logout button as a Hyperlink with a url parameter that forces logout, allowing the sublayout to be cacheable with the VaryByQueryString parameter.   Another alternative is to link to a completely different page that performs the logic, requiring no inherent varying of the caching of the original sublayout at all.  Finally, a developer may consider a custom Vary By parameter to handle the postback scenario.

Custom VaryBy Parameters

A developer may easily find his or herself in a situation where the standard VaryBy parameters do not fairly represent the conditions by which caching can occur.  If the “Divide and Conquer” approach is not sufficient, it is possible to create custom Vary By parameters by one of two methods: using the VaryByParm property and manually specifying the parameter, or by extending a webcontrol base class and inheriting your sublayouts from it, as described in several blog posts by Sitecore experts John West and Alex Shyba:

Custom Caching Criteria with the Sitecore ASP.NET CMS - John West

Sitecore Output Caching: Kick it up a Notch - Alex Shyba

Once again, one must appreciate the caveat that optimization is an exercise in gathering low-hanging fruit, and an analysis of the effort in creating the custom parameter versus potential speed gain is important factor.

Control Hierarchy and DOM Considerations

In an ideal scenario, presentation layouts and sublayouts are divided up in logical manners, and each control only affects its own piece of real estate.  Every bit of functionality affects only the area where it “lives” in the control hierarchy, and caching potential is easy to determine.

In the real world, it’s common to see scenarios where controls, either in HTML output level or .NET functionality, need to alter other controls even when they are not in a direct parent/child situation.  An often seen example of this is when the HTML for a page is identical, but the dimensions of objects are changed by swapping out a different CSS class on high-level elements, such as the body of the page, when some modular part of the page is there or not.

Take, for instance, a simplified scenario where a page’s interior dimensions change via CSS when there is no left nav. The following pseudocode HTML represents a page with such HTML:

<body>
    <div id="container" class="left-nav-with-content">
        <div id="leftRail">
            <sc:Sublayout runat="server" ID="slNavLeft" Path="~/layouts/Site/Nav Left.ascx" />
        </div>
        <div id="content">
            <sc:Sublayout runat="server" ID="slContentBody" Path="~/layouts/Site/Content Body.ascx" />
        </div>
    </div>
</body>

The “left-nav-with-content” class applied to the high level container determines the width of each div column.  Now, the same structure without a left navigation sublayout:

<body>
    <div id="container" class="no-nav-just-content">
        <div id="leftRail">
        </div>
        <div id="content">
            <sc:Sublayout runat="server" ID="slContentBody" Path="~/layouts/Site/Content Body.ascx" />
        </div>
    </div>
</body>

The HTML developer has left the leftRail div, and swapped out on the class on the main container for “no-nav-just-content”, adjusting the dimensions of the elements to hide the left nav.  If the existence of a left nav is static on a per template basis, this change can be statically applied in the presentation and work well with caching.  However, if the nav is dynamically present, say, based off of a checkbox called “Include Nav” on the content page, this makes caching of the navigation sublayout complicated. Since only the output of the sublayout is cached, that cached HTML cannot programmatically affect parts of the page in .NET.  It is impossible for it to be cached via normal VaryBy parameters and swap out the CSS class applied to the container div.

How can the issue be addressed?  There are several potential methods:

1. Ideally, the HTML may be rewritten so that the leftRail elements “push” the content elements, obviating the need to have a specific class on the container object.  Each element can be cached appropriately for itself, and the page reflows naturally. This approach is desirable but not always practically possible.
2. The swapping of classes may be handled by client-side scripting, where the information about the existence of a left nav element is done in jQuery or pure javascript.  This solution bypasses worries about caching, but is prone to having the page visually flash as the browser reflows the page after the document is ready.
3. Programmatically use FindControl to alter the class attribute based on the existence or visibility of the left nav.  The page itself can determine the state of the interior controls and write out the correct class.

All this goes to say that the hierarchical design of a site’s presentation plays an important role in the applicability of caching individual components, and care should be taken to account for caching during the design and cutting phases.