MIX Conference Channel

MIX Conference Channel - If you're a professional front end web developer, you care deeply about web standards and professional best practices like semantic markup, unobtrusive JavaScript, and CSS. And you're used to seeing Microsoft's web products painted in a not very flattering light regarding these best practices. It's practically cliche to see a litany of standards validation errors on a random Microsoft web site; especially ironic on web sites which are intended to sell the Microsoft web platform. And if you've been in this industry for any amount of time, you probably know people who have turned down contracts with clients who demand that the site be developed in ASP.NET or Sharepoint, because of a perception that "it's impossible to use ASP.NET to produce clean, semantic markup". While some of these past criticisms were warranted, things are changing rapidly. With the release of Oxite and the accompanying articles, you have everything you need to accept ASP.NET projects without abandoning professional web standards and practices. Oxite is the first and only ASP.NET based open-source CMS and blogging engine that encourages you to do "standards first, markup first" web site creation; a professional best practice on other platforms like Django, Ruby on Rails, and PHP. Nishant's article takes you step-by-step through "standards first, markup first" web site creation and the process of leveraging Oxite. And Molly's article can be used to convince skeptical business decision makers who might not yet be sold on standards-first web site creation. It's Our Job In the past couple of years at Microsoft, we've redoubled our efforts to support web standards. Examples include IE8 passing Acid 2, Visual Studio supporting JQuery, Expression Web built from the ground up to support web standards, and our web services stack baking in REST and JSON support. Because of our unique market position, Microsoft has a unique obligation to interoperability. In fact, Steve Ballmer and Ray Ozzie recently made it official -- it's our commitment and responsibility. So, if respect for web standards is Microsoft's official policy, why is it still so common to see skepticism regarding Microsoft products and web standards? This may be due to some lingering historical bias, but this alone isn't sufficient to explain the perception. The simple truth is that there are still plenty of sites and projects out there which don't produce clean, semantic markup (let alone markup that validates). I think this can largely be explained by historically different perspectives. For starters, many of the most vocal and influential .NET developers come from a background similar to the people in the Enterprise Java community (in fact, many are converts from EJB). For them, the markup and JavaScript are a side-effect of the backend code, and the most important priority is to factor the server-side object model, state management and code as elegantly as possible. The server code is the starting point and purpose, and the markup is essentially a "necessary evil" that is used to connect the code with an end user. Conversely, people coming from a professional front-end web development focus tend to see the markup (and JavaScript and CSS) as the most important part of the application. Elegant semantic HTML plus unobtrusive JavaScript make your application future-proof, open the door to automation, accessibility, and numerous other benefits. To these professionals, the server side code is less important -- a necessary evil that exists to connect their elegantly factored client markup and code with a database or other service. This isn't to say that one perspective or the other is "wrong", but it does help explain the historical dearth of focus on "standards first, markup first" samples on the Microsoft web platform. When the most vocal and prolific community members have historically seen professional web standards as being secondary to server-side code factoring, it's not surprising to see their samples, recommended practices, and products reflect those priorities. Enter Oxite We created Oxite, first and foremost, to show how easy it can be to support professional web standards best practices on ASP.NET. Nishant's article walks you through the process we used, and you'll notice that it's very similar to the best practices you would follow in Django, Ruby on Rails, or PHP. Don't ever let anyone tell you that ASP.NET is a different beast -- it *is* possible (and easy!) to start with clean semantic markup and have it emerge from the framework unscathed. In addition, we created Oxite to be something that you can download and use in your own projects. We provide source and a liberal license, so you can use and modify the software how you like. We provide you with fully working code, so that you don't need to become a backend coder yourself, but it's exciting to see people from the community already creating tutorials and providing information about how to extend and improve Oxite. Finally, you should know that there are other CMS and blogging platforms available for .NET, and Oxite isn't intended to be a competitor or replacement. One of the most exciting things we've seen as a result of the Oxite launch, is renewed attention to "standards first, markup first" functionality across the board. While the other engines don't claim to be focused on "standards first", you can fully expect that some will be tweaked soon to encourage and support professional front-end web engineering best practices. The positive feedback from those of you doing "standards first, markup first" development has been encouraging, and will undoubtedly influence all of us who build platforms. We’d love to hear what you think. Is there room for a "markup first" CMS running on ASP.NET? What direction would you like to see Microsoft products move regarding web standards?

MIX Conference Channel - The Web Standards movement is now in its 10th year. The goal of this world wide movement, which we see manifest in such organizations as the Web Standards Project (WaSP), Web Standards Group (WSG); a slew of specialized conferences and workshops is to unify professional best practices for the Web in order to establish a truly interoperable platform. Whether you're on your Vista machine or a Mac, using your iPhone or PDA should be irrelevant when it comes to the user experience. This is a prime initiative of the movement, and has its roots in the vision of the Web as Sir Tim Berners-Lee, its creator, saw it. Okay, you think, great. This is a technology issue more than a financial one per se. But with ten years of observation under our belts, those of us within the movement can clearly define the savings, return on investment, and value of using Web standards when creating Web sites and applications. This article will help readers, particularly those interested in better business and technology practices, gain an understanding of where the ROI is when it comes to Web Standards. Future-Proof Your Investment. The Web is a truly universal platform, and will continue to be supported and maintained long after other platforms have fallen by the wayside. New systems in the future will use the Web as the foundation. When you build using established Web standards, you are using those parts of the web most likely to survive and thrive in the future. You can be sure that your creation will continue to be supported by multiple vendors and devices far into the future. Building on Web standards now protects your investment in the present and continue to reap dividends in the future. More Efficient Management. Designing across browsers and managing documents efficiently has been the bane of the Web designer/developers existence. Following standards and practices allows for the creation of a workflow that saves not only time, but wear and tear on Web designers and developers working with these difficult challenges. Using a Web standards workflow, time, money and the quality of life for the most valuable of resources: the people on your teams can help improve this ongoing challenge in the standards environment. Search Engine Optimization. Perhaps the most compelling argument when it comes to value of standards is that if you are writing markup, CSS and JavaScript according to the standards ideologies, you are opening up a world of opportunity when it comes to better SEO. The technical reason is because a semantic markup document holding primarily linear text content allows search engines to find headers and critical keywords within text that much faster. Universal Access. Whether designing for a PDA or a visually-impaired individual, the concept of Universal Access (which includes numerous modalities such as phones, print, web site all coming from the same document as well as access for those with specific disabilities) is far more easily achieved using the techniques advocated by Web standards, making a document significantly more style-able and scriptable for those multiple reasons. Scalability. As sites grow, and they have a tendency to do so, a great deal of effort can be saved by having an existing standards workflow and corporate/organizational design guide. This empowers people to scale, refresh and even redesign sites with greater ease than in non-standard design, in which each page "carries" its design with it rather than being controlled by external style sheets. By separating document, presentation and interaction behavior on the technical side, a very significant amount of time, money and frustration can be avoided as a site grows. Improved User Experience. The lighter-weight files associated with standards-based design mean an improved experience for the user. In order to be effective, sites have to be easy to use and allow the user to get to their goal quickly. A clean infrastructure and the smaller files typically resulting from a Web standards workflow can have a significant impact on the load time and responsiveness of a site, keeping your users happy customers. These are the key business reasons that Web standards and practices are essential in today's professional Web building. We have process and standardization in almost every other area of computing, but the Web is truly a new frontier. It's the savvy Web pioneers who build strong foundations for future bounty and success.

MIX Conference Channel - Let's Do Something Brutal [1] First off, check out the prior iteration of MIX Online: The site used to be a simple blog that, save the prolific content, left much to be desired. It was hardly representative of what the MIX brand stands for. As we started talking about the goals of the site, a few themes emerged: Content. Content is king, and we agreed that instead of a stream of blog posts, we would invest time in publishing rich articles on topics that web professionals would find interesting. Bits. The MIX Online team tends to explore interesting scenarios on the Web by building real software. We wanted to somehow weave that into the site in the form of software that we could give away. Design & Standards. The site needed to be beautiful inside-out. The new MIX Online would connect with the common user to the web designer to the web standards advocate. We never really turned the above into a vision document, but over the period of brainstorming and discussions, the vision became pretty clear in the minds of all the folks involved. What's important before you dive into any design exercise is to gain a clear understanding of the purpose of your site. It doesn't need to be formal, and it doesn't need to complete; you can fill in the details as you move forward. But the high-level picture should be crystal-clear. I can't recall many days when I don't reference the original vision in some conversation or another. As a web site evolves, a clear vision becomes the designer's most frequently used tool in helping ensure a sensible evolution. It becomes infinitely helpful when an executive goes, "Why don't we move that above the fold?" "Well, we could do that, but let me remind you that that pretty much changes our original vision. If that's cool with you, I can go make the change," is always a more effective way to solve the problem than responding with, "You are not the boss of me!" or worse, "You smell like poop." Paper or Plastic? Get yourself a vertically-oriented, graph-paper Moleskin, and you will open your world up to all sorts of possibilities. Yes, this is the customary section on "design begins on paper." Before you get turned off, I'll share a secret that may serve as consolation: until recently, I had always felt that paper got in the way. From design books to shows (like the ones on HGTV), we've been exposed to sketches for everything from web sites to interior design. A couple of things always baffle me about most of these sketches: They often look exactly like the finished product. They're beautiful. All the lines are clean, shadows in the right place, perfect grid systems, and so on. We've been subconsciously conditioned such that whenever we try to sketch an idea out on paper, we're aspiring to produce sketches like the ones I just mentioned. Years of unsuccessful attempts later, I've finally dropped the dream of sketching masterpieces and that's helped expose the true value of the pen and paper in the design process. Specifically: It's low-cost. It's quick (and, it's OK for it to be dirty). It helps you dive into details. Paper should be used as a tool to facilitate brainstorming. You can use it for any aspect of the design from feature prioritization to layout. If you find yourself struggling to introduce a paper and pencil into your design process, you're likely working against the natural grain of your thought process. Or, you've probably set up unrealistically lofty expectations from the mighty paper and pencil. My advice is to expect paper to help you explore and capture the images and ideas in your head, and nothing more. And if that means that you write down random lists of ideas, great. If that means that you sketch out site layout, even better. If it means that you draw intricate shapes that accrue to logo designs, I salute you. Whatever it is, know this - paper is a very powerful first step to designing something, and embracing it will bring you only good. Feature Wireframes for the Liberated Designer As of late, I have found myself creating something I call "Feature Wireframes" because they find the sweet-spot between specifications and real wireframes. Feature wireframes, despite looking exactly like traditional wireframes, only capture functionality without making any guarantee about typography, color, or even, layout. That's where they differ from wireframes as understood by most UX professionals today which often capture layout. I prefer to save the layout exercise for my late night design sessions. There are a few benefits to creating feature wireframes: Designers think visually; trying to picture the site in the form of a feature wireframe forces you to think about the details, and subsequently, the feature set of page. Layout is one of the most important parts of a web design, and trying to finalize it within the first couple of weeks of the design phase seems counter-intuitive. Feature wireframes decouple the layout process from writing specifications, and keep the project moving forward. They unblock the development team who really only care about rolling up their sleeves on the core features of their site. Before we move on, it's probably worthwhile mentioning that feature wireframes are not for everyone, or every situation. But if you're on a project with a set of stakeholders who trust your design chops, feature wireframes can be extremely liberating because they give you much-needed freedom to explore the best design solution. I Scratch Your Disk, and You Scratch Mine Once a rough vision is in place, and feature wireframes are pinned to the corkboard behind your screen, you're ready (and generally itching) to roll up your sleeves, fire up your favorite illustration tool, and start painting pixels. The process I use is very similar to how professional interior decorators recommend designing a room: pick an object in the room as the focal point, and design the room around it. While the feature wireframes aren't completely representative of the layout and elements in the site, they generally have some good ideas that you can use as a starting point for the site design. Finding Inspiration "Good designers borrow; great designers steal. Kicking off visual design for a web site is possibly one of the most difficult parts of the process. It's very difficult to commit to a visual identity; almost as difficult as actually coming up with one. Something that really helps me get over "designer's block" is browsing through CSS showcases. A while back I found Tanya Merone's portfolio through a CSS showcase, and I've been hitting it ever since because her Favorites section neatly lists most of the CSS showcases around. So, Tanya, if you've been getting a boatload of hits from Redmond, WA, that's me. I spent a considerable amount of time looking for inspiration for MIX Online during this phase. I bookmarked a few sites that inspired me, but nothing really blew me away. In an effort to keep the project moving forward, I moved onto the next phase: visual prototyping. Visual Prototypes Whenever I enter the Photoshopping phase without true inspiration (and generally, this happens more often than not), I account for some failed concepts. I call these "Visual Prototypes". If you ever find yourself not entirely sure of the visual direction your site needs to take, but need to stay on schedule without compromising your quality bar, push forward. It'll click eventually, but the key is to not get stuck. Stay unstuck. And, thus, a good 30 hours of time was spent in Photoshop between two completely different concepts. I completed neither, but each explored different visual motifs, navigation metaphors, and layout. I now boldly go where no designer likes to go. I present to you, the failed concepts. Yes, they look nothing like the final design, but if you squint, you'll see several elements that made it into the final design. The lesson here, if there is one, is that prototyping is not just for engineers; it's for web designers, too. While visual prototyping doesn't work seamlessly, your comps will likely look like crap, and you'll have to throw most of the work away, it'll help you figure out some key stuff that will be integral to the success of the final pass. The "Aha!" Moment As designers, we're conditioned to pretend as if the design process adheres to a deterministic algorithm: gather requirements, create use cases, create wireframes, and so on. When we don't, it makes the rest of the team uncomfortable because it introduces unpredictability into the schedule. But the reality of the matter is that if you're looking to design something unique and excellent, it rarely follows some predictable path. You tend to collect data and iterate back and forth between all the phases I mention above, and at some point, the right nerves fire, the moons align, and you have that "Aha!" moment. The "Aha!" moment on MIX Online came sometime toward the end of the Visual Prototyping phase. Like many fellow designers, I am on the long list of folks who often visit Veerle's blog not only because she's an awesome designer, but also because she publishes some great content. I came across an art post she did on James White, a Canadian designer [2]. The first piece on this post, titled "Commodore", just blew me away. It had all the elements of a strong visual identity fitting for a site like MIX Online. Don't fight the "Aha!" moment and don't be ashamed of it. It's natural. Embrace it, and communicate its existence to your team without being arsty-farsty about it. Just be straightforward. If they're smart and value good design, they'll accommodate for it. If not, well, you know what to do, right? It's a win-win. The Final Pass Jumping back into color comps after the "Aha!" moment has taken place is a wonderful feeling because you can almost picture the whole site in your head. All the pieces finally fit together. In the case of MIX Online, the inspirational piece allowed me to quickly make some key decisions that you now see on the site: The Commodore branding has 5 unique and very saturated colors. Coincidentally, we'd decided by then that MIX Online would have 5 unique sections. I decided to pair each section to a dominant color: link colors, footer elements, logos, etc. would all change based on the current section of the site. The site would embrace sharp edges and a clean grid as these are both characteristics of the retro olden days of computing. I experimented with type and final settled on a combination of Georgia and Lucida Sans. While Lucida Sans is a pretty commonly used typeface on the Web today, Georgia seems to have become increasingly sparse. All the more reason to help Georgia's wonderful curves make a comeback. The lab section would provide an aggregate view of all our bits, but each lab would get its own section. This was a pretty natural choice because each lab is different from the next and potentially has a different audience, different elements, and so on. The 80/20 rule couldn't have been truer than what it was on the MIX Online site design. In the final pass, I created approximately 8 comps. Each captured a core section of the site, and the whole pass took just a work week. Comparatively, we spend a good 4-5 weeks brainstorming, capturing requirements, prototyping, and analyzing the site design. Slice, Dice, Toss and Turn Sign-off was pretty easy because pretty much everyone knew what was going on through the process. There's a fine balance to be drawn between showing too little and showing too much through the process, but if you can get away with it, err on the side of too little. This is clearly just a preference of mine and I'll spare you the reasoning. If you don't have that sort of freedom, your ability to communicate clear timelines and status can go a long way in buying you that freedom. In any case, you should always spend a reasonable amount of time communicating the status of your progress and setting reasonable expectations for delivery. There are loads of services out there that take your PSDs and promise to turn them into standards-based, semantic markup for very reasonable rates. Essentially, these are shops that employ front-end web developers - often in other countries - and project-manage the slicing and markup exercise from somewhere local. In theory, it's a great idea, and if you browse around you'll find that others with good credibility in web design such as Jonathan Snook, have written positively about it. As much as you may not want to, you may need to farm out XHTML/CSS development due to scarcity of development resources. After reading others' experiences with slicing services, and peering through sample code on several of the services' sites, we decided to go with a different service. While our experience was not as excellent as Jon's, we did get the whole site marked up in a week. And, it validated. But was the code semantic? Not really. It's beyond the scope of this article to cover that, but watch out for an opinion on the topic in our Opinions section. So, there we were, stuck with markup that validated but often made us cringe. What now? The Platform Saves the Day We did what good corporate citizens do: we shipped. We decided to clean it up as much as we could, and shipped it, fully knowing that we were going to refactor most of it in the future. Fortunately, our shiny new platform - built on the same codebase as Oxite - allowed for swapping out views without affecting anything else on the site. Oxite is built on a framework called ASP.NET MVC that was released by Microsoft to help web professionals build standards-based sites, something its parent technology, ASP.NET, always had trouble with. The framework is built on a very popular design pattern - chances are that you've used it unknowingly - known as Model-View-Controller, or MVC for short. The pattern essentially provides a way to decouple the presentation layer from the data model and business logic of a software application. The capabilities of your CMS are of utmost importance to you as a designer because it informs the requirements exercise early on. If you're designing for WordPress, you will likely have different options available for you than if you are designing for Sharepoint. Of course, understanding the capabilities requires you to delve into some technical aspects of web design. You don't need a Computer Science degree, but an understanding and empathy for programming can go a long way. I frequently encounter web designers who take pride in not having to think about the "technical" aspects of site development, and avoid anything remotely related to programming like the plague. They create comps and leave it at that. If I may offer my two cents, I believe that attitude is on path to extinction, and those web designers will have to revert back to graphic design eventually. If that's your thing, then cool; there are great careers to be made out of pure graphic design. But if you're serious about building a career designing for the Web, it's time to start sifting through the technical shelves at the bookstore, and biting on a topic or two. If you look across the board, the best web designers out there are very technical. Take Shaun Inman, for instance. Not only does he have a fantastic grasp of graphic design, but he can also take XHTML, CSS, PHP and JavaScript for a good spin. I know, I know. You hate me for saying this, but I am just the messenger. I suggest that if you're affected by what I just said, bookmark this article, power down your computer, and go buy yourself a few pints of Stout. I promise it'll make it better. When you're done, go buy a book that inches you toward your dream of being an awesome web designer. This one will give you a rock-solid start. OK, I'll get off my soapbox now. 3... 2... 1... 404! The last few hours are always frantic - emails flying all over the place, assets being created on the fly, last-minute code fixes that cause regressions, managers doing drive-bys to get status updates, your significant other IM'ing you wondering when you're going to be home and if you're going to have time to drop by the vet's to pick up food for the cats whom you can hear frantically meowing in the background. No matter what amount of planning you put into it, the pre-launch hours inevitably get chaotic. But don't read that as, "Don't plan. It doesn't help anyway." On the contrary, plan it all. Get it on paper and get everyone to sign off on it. Even better, create and assign tasks in your bug database. If you don't, it's only going to be worse, and you may slip your launch date. In no particular order, here are some suggestions on how to make the launch exercise as painless as possible: Clearly identify the launch owner. There can only be one, and that individual is the axle for the wheel of your launch unicycle. In times of crises, it is critical for one person to be at a vantage point that affords them the ability to "make the call". If you're the owner, start capturing each and every detailed task that needs to be completed in order to launch. No task left behind should be your motto. Assign an owner and a due-date to each. Delegate. Communicate frequently. Deflect last-minute design requests like Teflon. A simple way to deflect is to turn it back to the requestor, "Would you block launch if that's not in?" Only accept "yes" or "no" for an answer. Logic always prevails. Do frequent passes through the site. Expect things to break until the last minute. Keep a sense of humor about you. As one of my old bosses over at Amazon.com always used to say, "It's just a site. It's not like we're curing cancer." Honestly, there's an entire article to be written around "Launch". You need to hit the finish line, and all the decisions you make should help you get there. This isn't to say that you need to launch at any cost; I've been on teams that triage ridiculously important bugs to hit launch, and that's just not how it's done. Make the wise choice for both your customer and your company. The Real Fun Begins The day after launch is generally a busy day because you quickly switch to maintenance mode. Not to mention, all those feature requests that you punted before launch come racing back into your inbox. However, what's more important is that your site is online. Customers - real customers - are hitting it! It's daunting because all those things you fought for and protected during the design phase for the customer are now in front of that very customer. What if the customer doesn't like the design? Time for a quick pop quiz - Q: What counts as valid customer feedback? Someone at your company emails you and says, "I'm not sure that image is encouraging the audience to click." Your wife emails you and says, "I really don't like that color." Your colleague drops by and says, "Nice site! But I have one issue with it - I absolutely hate the way I have to click this to do that." Your boss - despite signing off on it earlier - says, "I think we need to do something about the placement of that text. I don't think it works where it is." All of the above. None of the above. If you picked (e), you win. You thought it was (f), didn't you? Shame on you. It's easy to forget that on the Web, the world is your user base. Some are more important to you than others, and you should absolutely factor that into making decisions around evolving a design. But accept the fact that everyone is a user, and all feedback is innocent until proven guilty. The sooner you accept that, the easier it's going to be for you to design killer sites. All I'm recommending is that you hear everyone out; you could justifiably ignore all the feedback, but don't do it before you've assimilated it. Try to detach yourself from the need to think of it as criticism, and instead think of it as a clue that something may be broken. Once your site has launched, you're an investigator - always searching for clues - trying to make your site reach its potential Zen (instead of trying to solve a mystery). If you're a perceptive listener, users do all the heavy-lifting for you by giving you these clues. Combine those with site analytics tools and you're bound to succeed. In a Gist "I saw the angel in the marble and carved until I set him free. - Michelangelo My contention is that the web-design process - and more broadly, the software-design process - is barely understood. There are few who, through sheer creativity and experience, have found their own balance and rhythm in designing great web experiences. The wide majority, however, are still struggling to rationalize it and are still a ways from being able to standardize the process. But maybe that's the very problem - one can't follow a one-size-fits-all template when designing web and software experiences, because at some level it's more art than science. Whether that's true or not, one thing is for certain: there's much to be discovered, and the journey has just begun. Colophon Jesse Bennett-Chamberlain's most-excellent write-up, Redesigning the Expression Engine Site, served both, as inspiration, and as validation for many of my own trials and tribulations around the web design process. Tanya Merone's bookmarks have saved the day time and again when I'm seeking some inspiration. Check out our very own blogging platform, Oxite. ASP.NET MVC is a framework that allows you to completely decouple presentation from business logic in web development. Windows Live Writer is how we publish posts on MIX Online. This article was published through Live Writer. Footnotes [1] Note to readers. Whenever you see the world "brutal" on this site as written by one of us, it's a good thing.™ [2] Check out James White on Flickr, if you're looking to be blown away by some really original work.

MIX Conference Channel - Oxite Oxite is an open source, standards compliant, and highly extensible content management platform that can run anything from blogs to big web sites. We know this because it runs MIX Online. Download Oxite from Codeplex but if you must, scroll to learn more What's in the bag? Everything You Could Ever Want (and more!) When you roll your own blog or web site, you are faced with a huge list of protocols and features that you need to implement, but all you care about is building the best web experience you can dream up. Oxite provides you with a strong foundation you can build upon - pingbacks, trackbacks, anonymous or authenticated commenting (with optional moderation), gravatar support, RSS feeds at any page level, support for MetaWebLog API (think Windows Live Writer integration made easy), web admin panel, support for Open Search format allowing users to search your site using their browser's search box, and more - so, you can spend time on designing a great experience. Create more than just blog posts. Oxite includes the ability to create and edit an arbitrary set of pages on your site. Want an 'about' page? You got it. Need a special page about your dogs, with sub-pages for each of those special animals? Yep, no worries . the ability to add pages as a child of another page is all built in. The web-based editing and creation interface lets you put whatever HTML you want onto your pages, and the built-in authentication system means that only you will be able to edit them. And if that's not enough, well, you have all the code, don't you? Lone blogger, or part of a pack? Oxite includes support for multiple blogs on one site, as well as the ability to contain the data for more than one site in the same database. We heart you so much, that we thought of everything. Oxite was developed carefully and painstakingly to be a great blogging platform, or a starting point for your own web site project with CMS needs. Its line-up of sexy attributes includes: provider-based architecture allowing you to swap out database and search providers (SQL Server DB, local and Live search providers included), built for testability and hence most likely to be voted "hottest in class" by TDD fans (repositories, everything has an interface, etc.), database file and string resource storage so that files get stored in database and strings stored for localization, built to take full advantage of ASP.NET MVC but broken into assemblies so that even ASP.NET WebForm developers can use the data backend and utility code, supports use of Visual Studio Team Suite (DB Pro, Test, etc.), and Background Services Architecture (sending trackbacks, emails, etc. all done as a background process to prevent delays on the web site itself). Learn from MIX Online. We know how frustrating it can be to get going on building a great site on a powerful platform. We're providing a default template to get you started, but fret not if that's not enough. If you're anything like us, you learn best by sifting through code. So, we figured that we'd package up MIX Online codebase for your perusal. If nothing, it should give you a rockin' good start at building your own site. Screenshots Video <object data="data:application/x-silverlight," type="application/x-silverlight-2" width="320" height="240"> <param name="source" value="http://www.visitmix.com/ClientBin/VideoPlayer.xap"/> <param name="initParams" value="m=http://mschnlnine.vo.llnwd.net/d1/ch9/4/8/8/6/4/4/TCSOxite_Essential.wmv,thumbnail=http://mschnlnine.vo.llnwd.net/d1/ch9/4/8/8/6/4/4/TCSOxite_Essential_Thumb.jpg"/> <param name="background" value="#E0F9F9"/> You need Silverlight to view this video. It’s fast, it’s free and it’s awesome. Click here to get it. </object> A Quick Overview of Oxite In this video, Adam Kinney, one of the early cofounders of Oxite, talks to Erik Porter and Nathan Heskew about what exactly Oxite has to offer. Erik and Nathan take you on a whirlwind tour of everything in the Oxite bag. If reading is not your thing, this video is for you. (6m42s) Be sure to check out our lab for more cool stuff. Related Articles Web Standards: Where the ROI isby Molly Holzschlag Web Design from the Gutby Nishant Kothary Quick Links You can download the Oxite source as well as check out example implementations of Oxite on CodePlex. Got questions about the project? Check out the discussion forums. Drop us a line if you're interested in contributing to the project, or simply get started.

MIX Conference Channel - It seems like everywhere you turn these days, there is more bad news about the global economy. Bankruptcies, layoffs, and bailouts continue to mount. We are hearing the words "recession" and "depression" more frequently than ever before in our lifetimes. The truth is, the world is in the midst of a severe economic crisis, and the end isn't yet in sight. But if you do software, web development, or media, you have good reason to be hopeful about the future. This is the time to hunker down and continue growing your skills and experience, because what you do will be more important than ever. Unlike some of the other industries hard-hit by the crisis, we've already been through this before. The information technology sector alone lost 700,000 jobs when the Internet bubble burst in 2000. These were permanent job losses, never to be recovered, and even the most pessimistic estimates predict only a fraction of the losses this time around. Our industry is paranoid by nature, and we've watched a number of failed business models go by the wayside since 2000, while new models have emerged. There will still be some painful lessons to learn before the worst is over, but our industry as a whole is much stronger than we were 8 years ago. The real reason for hope, however, is the nature of software itself. Software is one of the most scalable forms of human value creation ever achieved. When you write a piece of software, your skill and effort can benefit thousands, millions, or hundreds of millions of people with almost no incremental cost to you. Web developers understand this intuitively. Facebook expends almost zero incremental effort to propagate new features to 100 million users. The same holds true of traditional skrinkwrap companies. Adobe Software, who spend heavily on research and development, still enjoy 80% profit margins when expenses are accounted for. Microsoft, Google, and Apple enjoy similarly high margins, and it's not because we are geniuses -- it is because software is such a superbly scalable way to provide value. This wasn't always a matter of common agreement. There was a serious debate in the 1990s about the value of software. Some companies felt that software was simply free "bait" that could be used to sell hardware. Those companies are now defunct. And most importantly, companies like Google and Apple (and of course, Microsoft) who focused on software, have done well. This isn't to say that hardware is defunct -- back in 2004, Steve Jobs famously explained that the iPod is simply "software in a box". The complete experience requires you to purchase the proprietary hardware and pairs you with the iTunes software service, but these are essentially mechanisms to prevent piracy. The real competitive advantage is in the software. The mobile handset companies who have done very well, all realize that their hardware is a mechanism used to sell their software experiences, and not vice-versa. Likewise, Google's crown jewel, the pagerank software, is kept secret from most Google employees and is hidden behind a service, yet can benefit millions of users by being made available over the web. You already know that creating software is hard. Skilled user experience professionals, developers, and testers don't grow on trees. Traditional software (whether in a file, in a box, or in a cloud) will be more important than ever, and the massive changes taking place in the world economy will present some new opportunities for skilled people to contribute to the common good. Software will be needed to help fill the holes left by the decline of mainstream news organizations. Software will be needed as spending on energy independence increases drastically. Software to make healthcare more efficient, software to help citizens connect more effectively with government and social programs, software to educate, inform, and inspire. Yes, software will be more important than ever. There may be lean times ahead for all of us, but there is no better time to start getting better at what you do. So, what are the trends in software that get you excited about the future? Where do you think the biggest challenges and opportunities lie? We'd love to hear from you. And don't forget to subscribe to the RSS feed or follow mixonline on Twitter to get future updates.

MIX Conference Channel - In a world of super-sizing and "Go Big or Go Home!' tag-lines, it is sometimes hard to go against convention and embrace your smallness. Success appears to be made of quantity more than quality. I tend to believe that you can be successful by embracing your smallness. Smallness requires you to focus on what is important. For example, our team is small. We cannot afford to do every thing. When you try to be good at everything, you find yourself not being good at anything. It is better to focus on the important things and do less, than to try to do it all. Smallness allows you to change quickly. Question: what can change course faster, a battleship or leisure boat? Have you ever tried pulling a meeting together with 9 people to make a decision? I once tried, and the only hour where everyone was available was 8am, 2 months away. Smallness can help create nimbleness. Big organizations can embrace their smallness too. Just because you are in a large organization does not mean you cannot take advantage of smallness. You can break up big teams into smaller ones. You can look for the right behavior, not incremental behavior. You can apply constraints that force you to be more innovative. For example, ask yourself questions like "What if we didn't have a budget for marketing, what would we do?" or "What if we had to cut 50% of our upcoming feature set, what would we keep?" Smallness can make you define success in a different (and sometimes better) way. Many web sites look at quantitative measures for success. They may look at page views and consider success when they reach the 1M daily visitors mark, but is that the right measure of success? If you have an e-commerce site or a portfolio site, you don't want a high bounce rate, you want customers! Take time to think what success should be, you will be surprised how qualitative it just might be. Albert Einstein had a sign on his wall at Princeton that said: "Not everything that counts can be counted, and not everything that can be counted counts." Smallness can help to create a personal connection. People don't connect with faceless entities. They connect with people. Social networking is huge because of this. With smallness, people can learn about you, your opinions and ideals and connect with those things. There are great examples in my opinion of folks who have embraced their smallness like 37signals and our own local Jackson Fish Market. So let me ask you web designers and developers, how have you embraced your smallness?

MIX Conference Channel - Since we released Oomph last month, we've seen some exciting uptake from the community as people take the Oomph script and make it available in interesting ways: WP-Oomph Meitar Moscovitz has made a WordPress plug-in called WP-Oomph. The plug-in injects the Oomph script into your WordPress blog posts for you. GreaseMonkey Script Pascal Van Hecke implemented the Oomph script for GreaseMonkey, which is a plug-in for Firefox that does javascript injection. He has it hosted up at User Scripts. Bookmarklet Lastly, a thread on the Codeplex discussion resulted in making Oomph a bookmarklet which works across browsers. Please let us know if there are any other Oomph implementations or extension so we can let people know about them.  And thanks to all who have helped to spread Oomph thus far!

MIX Conference Channel - I will be speaking about Oomph at the PDC, which you can see up on the PDC sessions page. Tim, the designer on the project, will be there as well as Thomas, our fearless leader. We'd love to meet with folks if you are down in LA, so please feel free to get in touch if you'll be there. Here's more on the session itself (formatted as an hCalendar using the event Windows Live Writer plug-in.) Oomph: A Microformats Toolkit @ PDCMicroformats are about enhancing the web, representing data using HTML. Targeted at web developers and designers, Oomph makes it easier to create, consume, and style Microformats. Oomph is an amalgamation of applications: an Internet Explorer Add-in written in C++; a cross-browser HTML overlay written in JQuery; a Virtual Earth visualization that geocodes on the fly; a set of beautiful CSS styles; and more. Hear how and why we built it, as well as how you can be part of the burgeoning Microformat movement.Wednesday, October 29, 2008 3:00 PM to 4:15 PM Los Angeles Convention Center 1201 South Figueroa StreetLos Angeles, California 90015  United States I'll also be hanging at the client track lounge on Tuesday. From what I understand, Scott Hanselman, Jesse Liberty, and some other interesting MS folks will be there at that time as well. Here's that event formatted as an hCalendar as well! Hanging Out at Track Lounge Tuesday, October 28, 2008 3:00 PM to 6:00 PM Los Angeles Convention Center 1201 South Figueroa StreetLos Angeles, California 90015  United States

MIX Conference Channel - Here’s an eight minute demo of microformats and Oomph, so you can get a taste of what we’ve built:<embed src="http://images.video.msn.com/flash/soapbox1_1.swf" width="432" height="364" id="9qbneo9o" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" pluginspage="http://macromedia.com/go/getflashplayer" flashvars="c=v&amp;v=b205ba06-8956-423c-adf2-4d25c959afa1&amp;ifs=true&amp;fr=msnvideo&amp;mkt=en-US"></embed><noembed>Video: Oomph: A Microformats Toolkit</noembed>

MIX Conference Channel - You probably noticed the site looks a little different today than the last time you visited. MIX Online has been a community site for web designers and developers who believe that the web is a great place for innovation. In the past, the site has given you a varied perspective of what is happening on the web, a view into our conference called MIX, and interviews with amazing people with incredible ideas and stories on how you can take advantage of the web. But we were not content with resting there. We began thinking about how we could make MIX Online even better based on your feedback, audiences at our sister event, and people who have never even heard of MIX. We wanted to continue to be practical, conversational, innovative, unexpected and open. Our site will continue as a community site for web designers and developers who build and believe that the web is a great place for innovation. Here are some of the changes we have made based on your feedback: We will take more of a scenario focus around emerging web trends. For example, Microformats is an interesting movement in the web community and we want to introduce you to it and give you some practical guidance around it. We will continue to have our traditional blog, but we are renaming it under the heading "Opinions" that provides a more natural conversation with our small team. We will provide practical articles with each scenario we cover that are written by people in the community, not always Microsoft's perspective. We are providing freely downloadable, open source, and immediately useable prototypes. We not only encourage you to use these prototypes for your own projects, but to also submit code to the prototype project on CodePlex. We have a sister conference called MIX. We hope you have the opportunity to attend and continue to engage with us before, during and after the event. Please take the opportunity to visit, give us your feedback and ideas, download prototypes, subscribe, and most of all: keep talking to us, we are listening.

MIX Conference Channel - Web 2.0? More like Web 1.0. As many suggest the end of Web 2.0, and others announce the coming of 3.0, if we look at the heart of the web experience for most users, has much really happened since 1995? "By adopting microformats, you'll be helping to fuel the next generation of browser and search engine innovation. Despite the rise of CSS, Ajax, and Rich Internet Applications, two key aspects of our web experience are essentially unchanged since the days of Lycos and Mosaic (ask your grandparents if those names aren't familiar to you!). Let's take a look at how this really is the case, how it things could be different, and then see at how microformats can, and are already changing the web landscape, and how you can use them to your advantage in your own projects. Browsers 1.0 In 1995, what could you do with a web browser? Well, you could visit web pages, print them out, bookmark them. And that's about all. In 2008 - we can still visit web pages, print them out, bookmark them. And that's still about all. The role of browsers, and our experience as users is just about identical. If you think that's a stretch, here's a screenshot of the first widely used browser, Mosaic. And here's its great great grand child, Firefox With the exception of the search field, it's more or less all there on Mosaic. Search 1.0 The other central aspect of the web experience, one that just about any web user will do several times a day, is search. Of course, since 1995, several companies, culminating in Google, have dominated search, but the search experience is more or less identical now to the search experience in 1995. Here's the search experience then and now: We visit a search engine... We decide on some keywords for the kinds of pages we want