Typically, when Microsoft develops a product, it releases a collection of Community Technology Previews (CTPs) and betas to allow customers to see what kinds of features have been added to the product over the course of the development cycle. Expression Web, previously called Expression Web Designer, is no exception to this, and we recently released the first beta for our product. Unlike other releases though, you will see that one of the big differences between this beta and our previous CTP is that we have been busy removing, rather than adding features. We know that this is not the usual path for a product team, and it is often the case that when you see features pulled from a release, it is because the product team is running behind schedule. In this case, though, we are removing these features because you, our customers, have provided us feedback that some of our features were not appropriate for a high-end, standards compliant web design tool. I know that this is not something you typically expect from Microsoft, so I wanted to take the opportunity to explain.
So, what is being removed? Basically, we are removing features that rely on the presence of Front Page Server Extensions (FPSE) for rendering your website correctly.
FPSE actually plays two distinct roles for Microsoft’s HTML editors. The first is the role you may already be familiar with: FPSE communicates with your web server to download and upload files. This part of FPSE also makes link fix-up work. This is not the feature we are removing. Expression Web will continue to support the ability to use FPSE as a way to connect to your web server and perform link fix-up.
What we are removing from Expression Web is the second FPSE role: those features known as “bots” that use FPSE as a server-side scripting system. These bots, which we carried over into Expression Web from FrontPage, include things like Themes, Shared Borders, the Photo Gallery and the Hit Counter. In this role, FPSE takes web pages that have special markup in them - HTML comments that have a well-defined format - and uses the markup to generate a more complex set of HTML.
Note: Even though there are bots that don’t require FPSE on your server (because FrontPage and Expression Web contained an embedded version of FPSE), bots as a whole have significant issues and, for reasons that will be explained below, we are deprecating them.
Why did we do this, and what does mean for existing FrontPage customers that use bots? Let me explain...
When the Expression Web team at Microsoft first started planning, we had a dilemma. On one hand, we wanted Expression Web to be a modern web design tool taking advantage of the latest standards and targeting professional web designers. On the other hand, we knew that with FrontPage going away, Expression Web would be the primary web design tool from Microsoft. While the FrontPage market consisted mainly of consumers, hobbyists and small businesses rather than professional designers, we have a responsibility to these customers and we didn’t want to leave them high and dry.
This left us with a number of questions: How similar should we make the user interfaces? How much of FrontPage's feature set should we support? Some of these questions were easy to answer, and we quickly settled on an approach that would achieve the following goals:
This was a good start, but even after setting these ground rules, we were left with the following question: How much of the old FrontPage feature set, particularly bots like Navigation, Shared Borders and Themes, should Expression Web support? On one hand supporting these features would help users with existing FrontPage sites move over to Expression Web. On the other hand, these features were not necessarily attractive to professional designers. Some of the problems with these features include:
Our initial solution to this issue – the one you saw in our CTP – can be thought of as the 'layering approach'. In this solution we would incorporate nearly all of the existing FrontPage features into Expression Web for maximum compatibility. On top of this, we would add new features which were more focused on the professional designer, things like rich support for Cascading Style Sheet (CSS) and great design-time visualizations. This approach was nice because it would allow us to move our focus toward professional designers while still leaving room for the existing FrontPage customer base. However, this solution was not the best option based on feedback from designers who worked with our CTP, and because these features could leave you with a website that only rendered correctly on a web server that had FPSE installed.
As a part of creating Expression Web, we wanted to show professional designers more respect. We believe professional designers are folks who feel that the design experience – how something looks and how you interact with it matters. Our ultimate goal is to build the kind of interface designers love to use, an interface that inspires creativity. FrontPage might have worked best with FPSE, but we wanted to be sure Expression Web provided an excellent experience whether you use FPSE or not. Ultimately this issue is not about technology or about functionality, it’s about trust. One of the reasons I joined the Expression team was to help Microsoft build trust with the designer community, and part of that is letting you make the decisions on how to build your sites or where to deploy them. This is why we are deprecating bots and investing heavily (and will continue to invest) in our support for using FTP and other non-proprietary protocols for communicating with web servers.
We went back to the drawing board and came up with the 'upgrade' approach, which you will see in our next CTP release. It consists of three main tenets:
This approach has two benefits: If you are an existing FrontPage user who is interested in moving into the world of modern, standards-based web design, then you should find Expression Web to be a familiar environment in which you can be productive very quickly. On the other hand, if you are a new customer to Microsoft (with respect to web design tools) then you should find that Expression Web is a design-oriented, professionally focused web editor that is uncompromising in its support for creating standards-based web sites.
We are aware, though, that this will cause pain for those existing FrontPage users that do not fall into these groups. Ultimately, we believe that your best solution may well be moving into a more managed web environment like SharePoint, where the vagaries of html and standards compliance will not impact you. If you are one of the people in this situation, I hope that you understand why we made this decision. If not, well, my email address is Erik.Saltwell@microsoft.com
Erik Saltwell - Development Manager, Expression Web
There has been quite a bit of discussion about our last blog post, so I wanted to take a few minutes to respond to some of the persistent themes found in people’s comments. Specifically, I wanted to address the following two concerns:
First, let’s talk about Includes. When we first planned to remove bots, we knew that customers would find some pieces of functionality missing that they would want put back into the product (though not necessarily in the same form). Our plan has been that some of these components (for example Includes and the Photo Gallery) would be seen again in future releases of the product, though after redesigns that gave them additional functionality and/or made them more designer-friendly (in other words, fixing the issues that caused us to remove the features in the first place.
We agree, though, that this may not be enough in the case of Includes, since:
For this reason, we will be providing an Add-In after RTM that re-enables the ability to insert new Includes in Expression Web. In the mean time you can use Cheryl Wise’s snippet-based workaround for adding Includes, which can be found at http://by-expression.com/quick-bits/includes/index.aspx. Finally, in a future release you should expect to see a version of Include-like functionality re-integrated directly into the product.
Now, let’s turn to Page Transitions. It was our original intent to remove page transitions, but for technical reasons we decided that removing this feature was too risky this late in the release cycle. Please note, though, that we very well may remove this feature from one of our next releases.
In order to help everyone get the answers and information they need as quickly as possible, we’ve removed the Email feature from this blog. Instead, please use the following two resources to communicate with the Expression Web team and with the entire community of web designers that are using Expression Web: