Lisa Wollin : General

New FrontPage Developer Portal ... Sort Of

lisawoll — Sat, 25 Jun 2005 02:23:00 GMT

During the past several months (about eighteen, to be exact!), we've been working to redesign the FrontPage Developer Portal on MSDN. If you've ever designed (or redesigned) a Web site, you understand the challenges that can arise. After several starts and stops, a great deal of research, and many discussions with stakeholders across Microsoft, I'm really excited to finally be taking the newly redesigned portal live.

This redesign encompasses some fairly large changes.

Portal Home Page

If you visited the FrontPage Developer Portal prior to our redesign, you may have used links on the portal home page to navigate through the other pages within the portal. We removed the links from the main part of the home page and inserted content from and links to other important information, such as FrontPage blogs and popular newsgroup posts.

Another major addition to the home page is the profile section. In the profile section, we'll introduce you to FrontPage product team members and MVPs. They are people who develop or support FrontPage. Some of the names may be familiar because you may have seen them in the newsgroups; others may be new to you because they generally work behind the scenes. However, all of them are important to FrontPage users as they work daily to build a better product.

Navigating the Portal

Because we removed the navigation links from the home page, you might be wondering how you can access the pages within the portal. To navigate the portal, you can use the right navigation bar. The right navigation was always there, but we’ve enhanced it to make it even more useful. It lives on each page in the portal, so you can always get to any page in the portal from any other page. This feature makes navigating the pages simple and easy.

Getting Started

The Getting Started page was one of the highest hit pages in our portal, so we redesigned it to really help you get started. It explains the three main pillars around which FrontPage 2003 was developed and provides links to help content, product information, developer articles, and other Web sites where you can find more information.

Technical Articles

The Technical Articles page previously listed all technical articles under two main headings: Web development and extending FrontPage. Now the articles are organized according to technologies, so if you want information relating to JavaScript, CSS, or VBA, you can easily find just the articles that you want without having to navigate a huge list of articles on every possible subject except the one in which you are most interested.

Information Center

In our research, we found that our customers often wanted information that didn't necessarily belong in an article. But if the information didn't belong in an article, where did it belong? Enter the Information Center. The Information Center comprises pages that explain various Web technologies that Web developers often use as well as tasks that they want to perform.

The Information Center is probably the area of the redesign about which I'm most excited. Each of the pages in the Information Center covers a major technology or a specific task. For example, if you want information on cascading style sheets, you can go to the CSS information page to find general information, a list of articles in the MSDN library, and other resources and Web sites that contain more information on CSS.

Initially, we included the Web technologies that are most common for our users: CSS, JavaScript, ASP, ASP.NET, and databases; and we included one major task: e-commerce. We plan to add additional pages in the future.

You can get to all the pages in the Information Center from the right navigation bar. In addition, there are links to many of the Information Center pages from the technical articles page.

How Can You Help?

We redesigned the FrontPage developer portal for you. We looked at which pages received the highest hits; we determined where you were going from the portal; and deduced (based on search and metrics) what information you wanted most.

You can help us by telling us how we're doing and what we can do to improve. We've added ratings to several of the portal pages to help you tell us what you think. As we receive actionable feedback, we'll make changes and continue to evolve the FrontPage developer portal.

We have one goal in mind: make the FrontPage developer portal the place you go to find information relevant to what you do—develop Web sites with FrontPage.

Tools for Designing Graphics for Web Sites

lisawoll — Wed, 16 Feb 2005 02:31:00 GMT

In my various lives, I've worn a lot of hats, from teaching to marketing and desktop publishing (back before there were computers for the masses) to writing text and code, and in all those lives, wearing all those hats, I've worked with my share of computer applications. As a teacher, one of the things I told my students was that if you've worked with one Windows application, you can easily transfer those skills to other Windows applications.

I, personally, think this was true for DOS applications, too, although I'm sure many would disagree, and I think this is true of many, if not most, occupations that changed with the advent of the personal computer. For example, many who worked as desktop publishers for print media became Web designers. In many ways, Web design is very much like print design, and many of the design guidelines for print media apply to the Web ... but they also don't. It's hard to explain without an example.

One guideline of print media is the importance of white space. Of course, white space isn't always "white" but rather blank or empty space that has no text or graphics. Flip through any magazine and you'll understand what I mean. The advertisements that grab your attention aren't usually those that have a lot of elements on the page fighting for attention; they are usually the ones that have a few and in many cases one main element surrounded by empty space. There may be just a few words attached to an evocative image, usually something that causes readers to feel some emotion, encouraging them to buy whatever the ad is selling. Newspapers are probably the one form of print media that gets away with using up every inch of spare space with text or images, and most do this very well because they coordinate the different elements on the pages so that they all compliment each other.

On the Internet, white space is still important, but you rarely see Web sites that incorporate huge amounts of it. In fact, the only Web site I know of that truly incorporates white space is Google.com. Most Web sites try to fill up every spare pixel of space. Some do this very well, others very poorly. I would even go so far as to say that either Web sites do it very well or they do it very poorly. There doesn't seem to be a happy medium here. If you look at some of the popular sites, like amazon.com and msn.com, you see sites that are very busy but also very well designed because they coordinate all the elements to create a uniform whole. Even advertising coordinates in color and format with other elements on the page. By the same token, you can probably find exponentially more Web sites that are just as busy but don't coordinate the elements on the page nearly as well. Usually, these pages have multiple flashing ads with several different fonts and a rainbow of conflicting colors. Usually these are the pages that you can't get away from fast enough.

My point is this: many Web designers and Web developers didn't get started as designers. We didn't take classes and get degrees in design. We sort of grew into it as our jobs changed and grew. We designed a few graphics, and everyone ooh'd and ah'd. We designed a few Web pages, and our bosses called us a Web designer. Most of us, no matter how good we are behind a camera, wouldn't publicly admit that we couldn't draw a straight line if our lives depended on it.

That's where graphics applications come in. There are a ton of graphics applications available on the market, many (IMHO) so overpriced that even a veteran graphic designer couldn't use them enough to pay for them. However, there are some really good graphics applications available (some relatively inexpensive) that can make even non-designer developer-types look really good. Here are my favorite.

Paint. Okay, I'll say it again ... Paint. Everyone knows what it is, but many refuse to acknowlege that they use it. Everyone one who has Windows has it, and for the money (free), there are few graphics applications that are better. Okay, so you may not want to create a lot of intensive graphics in Paint, but there are some very cool things that you can do in Paint that you can't do in other graphics applications. For example, let's say you're designing a Web site or developing a Windows application and all you want to do is add a screen shot to a document or modify it just slightly.

Most if not EVERYONE knows that you can press Print Screen to take a screen shot (Alt-Print Screen to get just the active Window or dialog box), and since this copies a bitmap of the screen to the Windows Clipboard, all you need to do is paste the results into any document. But what if you need to edit it? Perhaps you're writing a spec and need to edit out or change some portion of a dialog to create a new look; perhaps you're creating a training handout that describes portions of an application and need to add callouts. There are a million and one reasons why you might want to edit a screen shot, and I don't know of another graphics application (at least not for the cost of Paint) that allows you to edit a bitmap pixel by pixel.

Now some of you are probably thinking right about now that you can't use bitmap images on the Internet, and yes, that is true (or rather you can but they're not as good as GIF or JPEG and not useful across platforms, etc.), and while you can save GIF files in Paint, the color fidelity isn't good, so I'd like to introduce you to another tool that costs just about as much as Paint.

Office Picture Manager. If you have any Office System 2003 application (and if you have FrontPage 2003, you have an Office System 2003 application), you get Office Picture Manager free. Yes, you read that correctly ... gratis. And you can do some pretty nice things with Office Picture Manger. You can save a bitmap as a GIF ... or JPEG ... or PNG ... or TIFF ... or you can save any one of those as any one of the other. You can change the colors, crop, rotate, flip, resize. There is only one thing that you can't do with the current Office Picture Manager that you could do with its predecessor (the one in Office 97, Office 2000, and [I think] Office 2002), and that is specify a transparent color. IMHO this is sad for those of us who work with Web images, but in every other way, the Office Picture Manager included with the Office System is a better application.

The scenario would go something like this: take a screen shot, paste it and save as a BMP in Paint, open it in Office Picture Manager, and export it into the format of my choice, usually gif. I often use Office Picture Manager to convert bitmap graphics and screen shots that I use in my articles to GIF and to resize them as appropriate to meet MSDN guidelines. Although more recently I've been using a different product, Office Picture Manager is a great choice and definitely a great tool to keep in your toolbox for working with graphics of any kind.

PaintShop Pro. This is a non-Microsoft graphics program developed by Jasc (www.jasc.com) that I've worked with, and compared to high-end graphics applications like Adobe PhotoShop, it's a terrific application for creating and manipulating graphics of all kinds. I love to use the different effects on photographs and for the money, this is an awesome application. I especially love that I can see what my image looks like with a proposed change before I make it. If I don't like what I'm seeing, all I have to do is click Cancel and my image remains unchanged. I'm sure I don't use it to its full capabilities, but I definitely like to keep it around for working on Web graphics. (As a side note, I actually preferred PSP 7.0 to PSP 8.0, but I have PSP 8.0 because it was the only one available when I purchased, and although it is good, IMHO 7.0 was better.)

A while ago I found instructions for creating repeating designs, which are great as background images for Web pages, in PSP 7.0. I can't remember if I tried the steps in 8.0, I've since forgotten how, I don't remember the URL, and a quick look at the PSP 8.0 UI doesn't provide any clues, but in 7.0, it was a simple task of selecting part of a larger graphic and selecing a "make repeating graphic" command. I don't see the same command in 8.0, so I don't know if it's possible. However, even with this deficiency (which is relatively minor since I don't use repeating designs on Web pages), PSP 8.0 is an excellent graphics application.

Picture It. For all the things for which I love PSP, I love Microsoft Picture It, but for working with photographs, I've never worked with a simpler, better application. It has some great tools for cleaning up photos, like adjusting the angle on crooked photos to erasing flaws. About a year ago, I had the opportunity to use it on photos for a furniture Web site, and I was amazed at how well it worked. For photos that had too much glare, Picture It allowed me to cut the glare and deepen the colors to a richer tone; for photos that were too dark, I could lighten them without losing definition. I've never gone googoo gaga over a graphic program, but this one gives me hours of enjoyment.

Visio. Recently, I've used Visio more freqently for creating images for articles, especially if the image isn't a screen shot, but Visio has a feature (IMO) that is very important for Web designers and developers beyond the ability to create or save images in Web-compatible formats. With Visio, you can create a map of a proposed Web site (which you can probably do in most graphics applications) and you can also map out the structure of an existing Web site just by providing a URL. If this ability exists in other graphics applications, I admit that I've never seen it. I was first introduced to this feature years ago (perhaps even before Microsoft acquired Visio), and I've found it a very useful tool when working with Web sites. As long as a site has pages that have links, Visio can map the structure of the site. The default is 3 levels deep and 300 links, but you can adjust these settings as you need to. Visio is, admittedly, the pricier of the graphics applications listed here, but if you work with multiple Web sites (perhaps as a consultant) or manage a medium to large web corporate site, this one feature alone makes the cost of Visio worth the expense.

Gif Construction Set. As I said, I've worked with a lot of graphics applications, but this is the only one I've worked with that allows you to create really cool text effects. You can do a lot more with it, like animated gifs (if you've read even a few of my posts, you've figured out how much I "love" animated gifs), but text effects is what I've used it for most. If you've spent any time at all working with Web sites, you know that in order to show special fonts on Web pages, either the visitor needs the font on their local computer or you create graphics to show the font. Gif Construction Set, developed by Alchemy MindWorks (www.mindworkshop.com), allows you to create very cool text effects with any font installed on your computer. You can set shadow effects, create outlined text with fonts that aren't outlined to start with, create scrolling text marquees (okay, yes, an animated gif, but it's text!), and a host of other special effects. For a great price, you get a great tool to add to your toolbox, and if you're unsure whether it will suit you, I think you can still download a demo so that you can try before you buy. (If I'm not mistaken, it's a full working version except that the images have text written across them until you register ... if I'm not mistaken.)

Of course, these are only a few of the graphics applications available, and most are much more expensive than the ones I've included here, but all of these (IMHO) deserve a place in a professional Web designer/developer's graphics toolbox.

Favorites

lisawoll — Wed, 12 Jan 2005 00:17:00 GMT

Gandalfe requested that I provide a list of my favorite blogs for the new year. The new year is almost two weeks old, so I'm a bit late providing this list. Before I continue, I have to admit something: most traditional blogs do not appeal to me. Why? I suppose for the same reason that autobiographies and reality shows don't appeal to me. Many blogs are nothing more than online diaries, which is about as exciting as watching water freeze (although the number is diminishing as more businesses move to blogging as a format for keeping in touch with customers), but I have found some very interesting.

About a year ago I read one that chronicled a guy building a patio/deck; it detailed everything from buying the permits to excavation and laying the footings to the patio party when he was finished. Cool. It was a bit prehistoric in that it didn't allow comments, but I thought it was a great learning tool if you wanted to build a deck/patio and wanted to know what problems to anticipate along the way.

Here's a list of work-related blogs for which I get RSS feeds:

Peter Torr -- Mostly, I like Peter's writing style. If you're interested in the browser wars, you'll probably enjoy his post on FireFox.
Joel on Software -- Joel writes mostly about general software development, and most of his posts are on topic, but even those that aren't are interesting. Joel always has something to say, and he says it very creatively. (As a writer, I have to admit that I'm just a bit jealous.)
FrontPoint -- FrontPoint is a play on words: a combination of FrontPage and SharePoint. The FrontPoint blog is moderated by three FrontPage team members and specifically discusses information related to the integration of FrontPage with SharePoint technologies (usually Windows SharePoint Services).
Kathleen Anderson -- Kathleen is a FrontPage MVP and a Web accessibility guru. She has categories setup, so you can filter FrontPage posts from other posts. According to one of Kathleen's recent posts, another FrontPage MVP, Dave Berry, has also setup a blog for FrontPage tips. I've only scanned Dave's blog, but it looks like he's providing some great information for FrontPage developers. I'll certainly keep my eye on this one.

That's about it for blogs, but there are several other places that I get ezines and RSS feeds that provide information, tips, etc. for Web developers.

SitePoint -- SitePoint has several ezines, some of which are useful and some of which aren't. They also have some blogs. I've read the blogs, but none of them are particularly interesting to me so they're not in my favorites list, but you might find them interesting. From what I can tell, most of these are technology focused, which means (to me, at least) that there is less wading through flotsam to find useful information.
JavaScript.com -- Generally I'm not too fond of Web sites that have a lot of advertisement (like About.com that is 70% annoying ads and 30% useful information), but JavaScript.com, an Internet.com site, has some great JavaScript code snippets.

There are several other ezines that I receive, all with varying levels of usefulness. You probably have your own list. What are your favorite blogs and/or ezines?

Choosing Colors for your Web Site

lisawoll — Wed, 15 Dec 2004 00:11:00 GMT

Whether you're creating your first Web site or you're a seasoned Web designer/developer, choosing colors is always problematic. You want to make sure that the color gives the right impression. As Katherine Nolan points out in her article Color it effective: How color influences the user on Office Online, no color is either positive or negative. All colors have both positive and negative connotations. In her article, Nolan has a table that lists popular colors and their common positive and negative connotations in Western culture.

However, beyond the psychological meanings of colors within different cultures, choosing colors that complement and coordinate well with other images on your site and perhaps even your company logo can be difficult. Add to that the fact that while there may be millions of colors on the color spectrum, only a limited number of these display well in Web browsers. Colors that do are called Web-safe colors.

To help you choose colors, you can find a multitude of color pickers online, many of which help you choose colors that are Web safe. Some color pickers are better than others, so today's post features several of the best color pickers I've found online.

The first color picker is one that came to me through SitePoint. I receive several e-zines, one of which is from SitePoint. In a recent SitePoint Design e-zine, they featured a color picker that blew away all the color pickers that I had seen previously. It's called Color Schemes Generator 2 and was designed by Petr Stanicek. What I like about this color picker is that it defines, based on selections that you make, coordinating and contrasting colors, and then allows you to reduce the colors to Web safe colors. All you do is choose your main color from the color wheel on the left, and then select the variation that you want to use. The up arrow in the right upper corner next to the list of HEX color codes allows you to move the base color around so that you can see what it looks like as a background color and as a foreground color. You can even see what the colors look like to people who have vision problems.

The PageTutor Color Picker II, the second color picker featured here, has long been one of my favorites. You can easily choose the background, text, and link text colors, and the page displayed on the right side of the page changes so that you can see what the page will look like if you use the chosen colors. The page even provides the HTML code and the HEX color values that you need to add to your pages.

Another very good color picker is VisiBone's 216-color Webmasters Color Palette. I like that I can add colors by clicking on the color in the color "wheel" and remove colors by clicking on the X in the bar to the right of the color wheel. All colors are listed with their RGB and CMYK color values as well as their HEX color value.

Here are a few more color pickers that are available on the Internet.
Dougie's Color Picker
DigitDesigns WebSite Color Picker
Colors4webmasters.com Color Picker
Dynamic Web Coding Color Picker
Web Colors 4096 Color Picker
John December's Hex Hub

These are only a few of what you can find on the Internet, but using them sure makes choosing colors more fun.

Creating an RSS Feed

lisawoll — Fri, 19 Nov 2004 20:48:00 GMT

I've had several people ask me lately and have seen questions on Office Online about how to create an RSS feed. For those of you who don't know what an RSS feed is, it's something that people can use to keep up to date with the content on a site. Generally, sites that frequently publish content, like news sites or magazines, offer RSS feeds to which visitors can subscribe. Then when they publish content, they update the RSS feed and people who have subscribed to the feed will get a list of newly published content. (This is probably a somewhat simplistic explanation, but that's it, in a nutshell.)

If you have a site that contains content, such as articles or stories, and you frequently update the site, then you may want an RSS feed to help your customers keep up with your updates.

What is RSS?

RSS stands for Really Simple Syndication (although I've seen some sites refer to it as Rich Site Summary, also). RSS is basically an XML document that conforms to a specified XML schema. Short of regurgitating all the information that is available to explain RSS, I'll let you review the following resources. The all contain great information about what RSS is.

What is RSS?
Introduction to RSS (from webreference.com)
RSS Tutorial for Content Publishers and Webmasters

These are just a few. There are a hundred and one more resources for RSS; do an Internet search for "RSS", and you will likely come up with your own list of resources.

There are several different versions of RSS schemas, many created by various organizations. (The first link in the above list (What is RSS?) provides a table that briefly describes each version.) I'm sure there are experts in RSS who have an opinion about which one is the best to use. I'm not an expert, so I'm not making any recommendation. The schemas can vary some minimally, others hugely.

RSS 2.0

To help you understand how the schemas work and how to create your own RSS feed, the following XML code shows the basic XML for RSS 2.0, which is the version MSDN uses.

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
 
   <channel>
     <title></title>
     <link></link>
     <description></description>
 
     <item>
       <title></title>
       <link></link>
       <description></description>
     </item>
 
   </channel>

 </rss>

Before I get too far, I should explain that this is not a schema reference. Technology at Harvard Law has a great RSS 2.0 Specification schema reference that you should use if you need specific information about the elements. Plus I stripped down the XML above (for example, I removed the comments sections) so that you could see the XML without all the added text.

Briefly, each RSS feed that adheres to the 2.0 version contains one channel element. Some of the child elements for the channel element are optional, but the title, link, and description are required. The channel element may contain one or more item elements. Many of the child elements for the item element are optional, but the title, link, and description are required. The above example provides the required elements for both the channel and item elements.

If you think of an RSS feed like a newspaper, the channel element contains the name of the newspaper, a link to the newspaper's Web site, and a description of the newspaper; then each item element is a different story in the newspaper, each containing the title of the story, a link to where the story can be found online, and a description of the story, which in some cases may be the full story.

Publishing your RSS file

Now that you've been introduced to one RSS schema, and you've likely read a bit more about the different versions, you should be ready to create your own RSS file for your Web site. You can create and edit your RSS file in FrontPage, Visual Studio, Notepad, or another XML or text editor. Once you've created it, you need to save it as an XML file (with a .xml extension) and upload it to your Web site.

Then you need to create a link so that people who want to can subscribe to it. Generally, you will want to use the little orange XML graphic and link the image to the XML file. I've noticed that most sites that have RSS feeds use the little orange XML graphic or a slight variation, but not all. I'm not sure if there are any rules about using the orange graphic, but it's very easy to identify so that those who are looking for an RSS feed on your site can easily find it. To get a copy of the image, just right-click on the image and save it locally, and then upload it to your Web site.

After you've created your first RSS file and provided the link to it on your Web site, all you need to do is update the file when you publish new content -- daily, weekly, monthly, or whatever works for you. I suggest that you don't save the same RSS file multiple times with different filenames. If you do, those who have subscribed to your RSS feed won't be able to keep their news aggregators updated without pulling the URL to the new file. Just update the file and reuse the same filename.

The RSS files that I reviewed had the most recent content at the top of the file. This allows subscribers to easily find the new content and move on. Again, I'm not sure if there are any rules to this, but if you want to know how subscribers will view your feeds, I would suggest either buying an RSS news aggregator or downloading a free trial version. I use Newsgator in Outlook, but there are many different news aggregators, so do some research to see which one works. In addition, different news aggregators may display the RSS feeds differently, so you may want to install more than one to see what the differences are.

Well, that's it. About the only thing I've done here is provide just basic information. There are many many many more resources online that will provide more detailed information about RSS and how to create your own feed. If you're new to XML, I highly suggest becoming more familiar before starting to create your own RSS feed. Once you have a basic understanding of XML and RSS, you should be able to create the RSS feeds you need for your own Web site.

FrontPage for Mac

lisawoll — Mon, 18 Oct 2004 22:35:00 GMT

I've seen several people asking for a version of FrontPage for Mac, so I wanted to start this week with a post telling those who are interested in getting a Mac version of FrontPage, that as far as I am aware, Microsoft has no plans on releasing any more versions of FrontPage for the Mac.

As far as where you might buy a copy of the 1.0 version of FrontPage for Mac, unfortunately, I have no idea. A version of FrontPage for Mac hasn't been release for about six or seven (maybe more) years, so it's pretty much off the market and Microsoft no longer supports it.

I have no recommendations for a comparable product for Mac, but perhaps someone out there does and will post a comment with a URL.

Web Design Continued . . .

lisawoll — Fri, 24 Sep 2004 00:28:00 GMT

A couple weeks ago I posted a short and sweet post about not copying the poor web design that other people do really well. (See Web Design: The Good, the Bad, and the Downright Ugly.) I wanted to continue that discussion today with a link to an article that went out in the FrontPage Insider Newsletter today called, 9 things not to have on your Web site. (If you want a subscription to the newsletter, register at Office Newsletters.

I've seen many questions in newsgroups and other customer posts about how to design Web pages. As the author of this article, Jeff Wuorio, points out, you can find a lot of people telling you what you should do (and sometimes that advise may be conflicting), but rarely do you find articles that tell you what NOT to do. This article lists nine things that you should NOT do with your Web site.

Wuorio talks about Flash animations, sound, and posting your photo on your home page, among other things. My post about adding sound to your web pages told you what I think of pages that have sound. Wuorio mentions Flash animations, but I want to include any animation, including GIF animations, that have a large file size, take a long time to load, and fight for attention with other images and animations that exist on the same page. Not cool.

Personally, I rarely like animations, Flash or otherwise, and I've rarely seen them done really well. Animations usually tell me one of two things: (1) someone is trying to sell me something, or (2) the person who designed the page is an amateur. (Or it may tell me that the person is really smart and bored to death: for example, the animation of the clock that follows the mouse cursor.) I've seen, as I'm sure you have, pages that use animated bullets in a bulleted list. Ugh! Okay, for a beginner, this may seem really cool, but if you are trying to sell something or have something important to say, don't do it. And if you are ever inclinded to using the animated bullets that come with Office on your Web site, just say NO. Please!

I think part of the problem is that some people design a Web site, with it's accompanying animations, like they would design a PowerPoint presentation. These are two different things. In front of an audience (the right audience), animated presentations can provide a humorous context for what the speaker is saying. On a Web site, if the audience doesn't understand the humorous context, the joke just falls flat. There's no fun in watching a comic die on stage, and there's no fun looking through a Web site that closely follows every rule of what NOT to do.

Using script to close a window, etc....

lisawoll — Sat, 18 Sep 2004 00:20:00 GMT

In a previous post, I provided JavaScript to open a page in a new window. It may sound funny, but once the window is opened, what does the visitor do when they're done with it? Generally, they can click on the red X in the upper right corner to close the window, but I've seen a lot of sites, and likely you have too, that provide a button that visitors can click on to close the window. This code is really easy, so today's tip is really short, but here goes.

The code to add a button that closes the current window is shown below.

<button onclick="javascript:window.close()">Close</button>

Alternatively, if you want to do this with text, you can use the A element and place the JavaScript code in the href attribute, as shown in the following code.

<a href="javascript:window.close()">Close</a>

There is one thing that you should know about this code. If you use the close method on a window that was not opened using script, Internet Explorer displays a message asking visitors if they want to close the window. In Netscape Navigator and Mozilla, the code won't work at all, and the JavaScript console displays the message "Scripts may not close windows that were not opened by script." So this example works best in a page that you display in a popup window using script code similar to the code I provided in my earlier post, open a page in a new window, mentioned above.

That's it. No magic here; nothing terribly complicated. Just simple code to close the active window. To use this code, just copy it into your page as is. When you display the page in the browser, you will see a button. Just remember that depending on the browser you use, it may not function or may not function as you want it to.

Well, that's pretty much my post for the week. It's been busy. I've been reworking the FrontPage Server Extension pages on MSDN. Okay, so this has been in the works for some time, but we've had a few glitches. The glitches seem to be smoothed, so if all works out well, we should have updated content available within about four weeks.

I'm reviewing all the feedback comments that people have provided as I update each page. That said, I want to give a plug for everyone disposed to rating MSDN articles. I don't know how other teams view this data, but in Office, we take customer comments for articles very seriously. Unfortunately, we can't always do anything about them.

For example, if someone rates an article as a 1, the lowest score possible, and provides a comment like, "This sucks!" or something negative about Microsoft, well, I hate to say it, but I can't do anything with a comment like that. So if you often rate, or even if you don't but would consider doing it if you knew that someone actually looks at your comments, please put in comments that help us to know how to revise the content. Were the instructions bad? Where? Which ones? Was something unclear? What? Be as specific as you can without writing a book.

Oh, and one more thing, although I have on occasion been known to respond to people who provide email addresses in article comments, I don't make any promises that the response will either happen or will happen quickly, so if you need assistance with an article and need a response back, the best way to do this is to send us an email. You can do this from our Feedback page. Just click Talk to Us, and an email window opens where you can write to us. I receive every one of those messages, and although I don't encourage it as a support mechanism, if you've exhausted all of your other options or need specific help with an article, I want to hear from you.

Alternatively, feel free to send me a message through my blog. Again, I respond to every message, and if someone provides an email address in a blog comment, I will often contact them directly as well as through the blog.

Have a great weekend.

Web Design: The Good, the Bad, and the Downright Ugly

lisawoll — Sat, 11 Sep 2004 06:43:00 GMT

My last two posts have elicited some strong reactions from some (hey, distressed, what the heck are ra-ra skirts?), so I decided to end this week with a comment about Web design, or rather what constitutes a good Web design and what constitutes a bad Web design. There are a ton of resources out there, like Jakob Neilson's useit.com, that tell people what to and what not to do. Some of these guidelines are based on what one person likes or dislikes, others are based on accessibility and usability standards, but I recently found one site that I thought hit the nail on the head WRT Web design. It's called webpagesthatsuck.com. Check out the Daily Sucker.

Learning Web design by looking at Web sites that suck is an interesting concept. We usually learn by looking at something that is done right or well, but the author of this site has a point. You can learn a lot about what not to do by looking at sites that do what not to do really well. A quick glance through search results usually reveals more than a few poorly designed sites.Do you know of a really good really bad site? Tell us about it and why you think it's poorly designed.

(Oh, and I've seen more than a few Web design firms and self-acclaimed Web design experts with poorly designed sites, so don't be intimidated just because someone says they can do it.)

Securing online content and images

lisawoll — Wed, 28 Jul 2004 17:57:00 GMT

The Internet is a great visual tool for displaying artwork and photos. However, because the source code for Web pages is easily accessible, there is no tried and true method to completely secure your copyright-protected work on the Internet, other than not posting them, any more than you can prohibit people from photocopying text in a book. I've seen a variety of ways that people have used to block stealing of photos and artwork that are posted in Web pages. One way is to disable the right-click, another is to replace the good image with a bogus image on mouseover. Both of these ways, at best, slow a visitor down. Let me explain why each of these do not provide a good level of security for your online content and images.

Disabling right click

I've seen many requests from people for script that disables the right-click on their Web pages. Very often, someone has seen this on another Web site and thought it was a good idea for securing their own artwork or photos. However, although a visitor doesn't have access to the right click for the page displayed, they generally do have access to the menu bar, and on the View menu, there is a Source option that allows people to open up the source code in a text editor, such as Notepad.

You may think that the source code isn't going to help them much, but it does. For example, say the following HTML code is in one of your pages, and this displays a photo that you took and are selling on your Web site.

<img src="awardwinningphoto.jpg">

Viewing the source gives the visitor the name of the image file, and the path to the Web page gives the visitor the rest. So, say for example the path to the page where the above HTML occurs is http://www.cohowinery.com/html/awardwinningphoto.htm. All someone needs to do is open up the file http://www.cohowinery.com/html/awardwinningphoto.jpg in the browser, and once they view it in the browser, they can right-click on it and choose Save Picture As.

Replace Image on Mouseover

Another trick that Web designers and developers use to prohibit stealing of artwork and photos is to replace one image with another image when the visitor mouses over it. This also would seem to be great for securing online images. After all, if they can't right-click on the image and choose Save Picture As, they can't steal the image, right? However, as with the right-click, the best this does is slow them down. If someone really wants to steal an image, they can easily view the source and get the filename and path to the image, and do what I described above.

Then how can I secure my images?

Many Web designers and developer would answer that question by saying to not post the images, but if you make your living out of selling your photos or paintings, this may not be an option for you, so there are a few things that you can do.

Post lower quality graphics. When someone tries to steal an image, they won't get a great quality picture, just a representation of what the image looks like. If they attempt to enlarge it, the quality will be poor enough to discourage even the most determined.
Use a digital copyright. A digital copyright acts as a digital signature, and as with digital signatures, you need to purchase a digital copyright and use a graphics application to add it to your images. I'm no expert on this, so I won't even attempt to explain how it works or how to do it. Take a look at resources on line from experts if you're interested in using a digital copyright for your online content and images. If I understand this correctly, a digital copyright doesn't print but provides a legally binding way for you to recover loses if someone appropriates your intellectual property.
Use a watermark on the image. A watermark is a usually text overlayed on top of an image, perhaps a copyright symbol, your name and the date. It will certainly discourage people from taking images, but it can also disfigure an image to the point where it may not be distinguishable. This option is my least favorite of the three. Why? If I want to print out a picture to see if it goes with my favorite bedspread or the couch in the den, the watermark disfigures the image to the point where printing it will not give me a good idea of whether the picture will work for me or not, making me far less likely to buy the finished product because I don't know if it's exactly right for what I want.

While the information age does bring new problems and opportunities for people to cause harm, as you decide what is best for displaying your artwork, photos, and other online content, keep in mind that most who come to your site are just there to browse and perhaps shop and buy. Consider how you want people to use your site and provide needed security without inhibiting how visitors will use your site.

Tell Us More ... comments from Tech Ed

lisawoll — Thu, 03 Jun 2004 22:36:00 GMT

Eray sent me his comments for the final days of Tech Ed, so here they are. He has a great tip buried in here for moving WSS pages from a test environment to a live environment. The Export/Import feature in FrontPage is great for this. He explains below how one customer uses it.

Someone once advised me, "When deciding on the level of technical depth for a demo or presentation, always err on the too technical side." I took the advice to heart, and during my breakout session, I took an ironic leap into the wonderful world of XSLT. Ironic because, with FrontPage2003, a user does not need to code to create useful web applications on top of SharePoint. However, the audience seemed to enjoy seeing the XSLT we generate for each major DataViewWebPart feature.

I showed them how we generate an xsl:template for each repeating data region. Next, I explained how the xsl:variable "Rows" uses XPath to select the correct node set to iterate on, and that view level filters are really just predicates on that same location path. I similarly showed how we accomplish view level sorts via xsl:sort and conditional formatting via xsl:if statements. The transparency of our generated XSLT seemed to resonate with the audience.

After the session, I spoke to a small group of attendees with solution specific questions. One of particular interest had to do with staging best practices. Another attendee suggested a nice solution: let each user develop their application within a private web. When ready to go live, use FrontPage’s web package feature (Tools, Packages, Export/Import) to pack up the application and then re-deploy on the live web.

Another interesting application involved entering data via the web, storing that data, and then viewing results of calculations on that data. That attendee used FrontPage’s List Forms on top of a custom SharePoint List to accomplish the data entry portion. They added the formulas to the DataViewWebPart by using <xsl:value-of select="XPath expression" /> where XPath expression represents the formula in XPath.

I spoke to one or two folks that would have like to hear more about SharePoint customization. While that wasn’t the topic of my specific talk, after my talk, I showed them the CSS classes SharePoint uses to theme its pages. I also pointed them to the www.sharepointcustomization.com web site, always a great resource.

Later that night I decided to check out MOM’s Rumble in the Jungle at the San Diego Zoo. I was quite surprised and maybe a little jealous to see my friend Jon, a technical product manager for MOM, get serenaded by Jessica Simpson on stage! I guess it’s like another saying I’ve heard, "Marketing always has the most fun."

Stuff ...

lisawoll — Wed, 02 Jun 2004 23:10:00 GMT

Moving, et al

My date with the moving van went well ... sort of. Long story, short: I bought my first house and moved from an almost 1500 square foot condo to a less than 1000 square foot house. I comfort myself with the knowledge that a house is a better investment than a condo, and I have a garage, which at the moment is still filled with boxes. It will take time to find room for everything, either that or donate it to charity.

While I was out, Dail took good care of you posting Eray's comments about Tech Ed. Eray got busy during the final days at Tech Ed but has promised to send a final wrap up later today. I'll post it as soon as I get it.

New Article Published

We publised a new article on MSDN called, Automating Repetitive Tasks in FrontPage 2003. This is an article for advanced end-users who want to automate tasks that they consistently perform. To follow Dail's lead, here's a quote from the introduction:

Do you ever find yourself performing the same steps over and over again? Perhaps you publish the same Web site to several locations and find yourself repeatedly typing the Web addresses into the Publish dialog box every time you need to publish the site. Or perhaps you want to add a reference to an external style sheet to every page in your Web site and don't want to open every page to paste the necessary HTML. Macros can help.

Call for Ideas

For some time I've wanted to ask everyone for suggestions for article ideas. Some of you have submitted article ideas in the form of comments, and I have tried to respond to each of you in one form or another. Thank you for your ideas. We want more....

The FrontPage portal on MSDN is designed for Web developers of all skill levels and developers who want to extend the FrontPage application. Unfortunately, we don't have a great way of determining, other than through feedback and ratings, what type of content to produce. Therefore, I'd like to ask you to post any ideas you may have for articles related to FrontPage development that you would like to see.

One of the hottest topics currently is working with ASP.NET and ASP.NET controls. We have published several articles and have more in the works. I am personally finishing up an article on creating managed add-ins and one that is an introduction to Web technologies for new and low-end developers. I will next be working on an article on customizing IntelliSense (which I am hesitant to publish but which was requested). We also have two or three articles planned that relate to working with SharePoint sites in FrontPage.

If you have any additional article ideas, please let me know. I'll get them added to our list of ideas.

Tech Ed

lisawoll — Thu, 20 May 2004 22:48:00 GMT

Next week is Tech Ed in sunny San Diego. Several from my group, including John Durant, the Office Developer Center Editor & Chief, are planning on attending. Unfortunately, I have a date with a moving van, so I won't be there, but my editor, Dail Magee will be posting daily reports from Eray Chou, one of the FrontPage Program Managers. If you're attending, have fun and please feel free to add your own observations to our posts. If you're not able to attend, the Office Developer Center will be featuring everyone's daily reports, and you may also want to take a look at John's blog.

Why We Love To Hate FrontPage

lisawoll — Fri, 07 May 2004 00:04:00 GMT

I wanted to get back to my "Why I hate FrontPage" kick. As some of you no doubt figured out from the responses to my original post, the thing I always hated most about FrontPage, the mucking with my code, was fixed in FrontPage 2003. If you've used it, you know that FrontPage is much more code friendly than it was in previous years. This is great news for those of us who love to work with code. If you haven't worked with it, I strongly encourage you to play with the online trial or order the trial CD.

FrontPage is no longer your mother's (or grandmother's) Web package. It's not just for beginners anymore.

As an exercise, I decided to do some additional research on why people hate FrontPage. FrontPage has a BAD reputation, and that's sad because there are some very cool things about FrontPage ... at least FrontPage 2003.

Problem #1: Background

Of course, the most hated issue was that FrontPage mucked with the code, but this was such a common problem in early WYSIWYG HTML editors, that I don't understand why people lay this problem solely on FrontPage's doorstep, except perhaps that the people who are complaining haven't used other WYSIWYG HTML editors and haven't upgraded to a version newer than FrontPage Express or FrontPage 97.

To give you a bit of background, the first Web package I ever worked with was ... okay, I'll say it ... Net Objects Fusion. I don't think even it exists anymore, and no wonder. The HTML code that it generated was as UGLY. I'm talking UHH - GLY! If you thought FrontPage was bad, you haven't seen anything. At the time I didn't know any better, but then I learned, and Notepad became my best friend.

Homesite came next, and it was much better -- definitely better than NOF and cooler than Notepad. (Side note: I was first introduced to Homesite because it shipped with NOF. Great tool, strange marketing strategy.) But even Homesite had problems with WYSIWYG editing. I remember once clicking on the design view in Homesite and getting a message that switching to design view would mess up my code (my words, not the actual message), and did I want to continue. No way! I had learned that lesson already, and I wasn't letting anything touch my code.

FrontPage 2003 really is the best I've worked with yet. (Yes, I have worked with Dreamweaver, and, No, no one paid me to say that!) FrontPage added several features in 2003 that were designed solely for developers. IntelliSense is my favorite. (Ah, visions of Homesite spin through my head...) Split view is a nice feature. And, most importantly, no more mucking up my code.

Problem #2: Dependencies

The second most hated problem with FrontPage is dependencies ... specifically FrontPage Server Extensions. (Yes, I hate them, too.) In FrontPage 2003, most of the FPSE dependencies have been removed. Now, when you use the Database Interface Wizard to add database results to a Web page, you can have the results returned in classic ASP or ASP.NET code. I have to be honest: I don't much care for all the webbot code mixed in with the ASP, but I'm sure it's there for backwards compatibility.

Although many of the dependencies on FrontPage Server Extensions are gone in 2003, FrontPage includes additional dependencies for Windows SharePoint Services. This can be seen as both good and bad.

I work with WSS sites every day. All my content goes onto a WSS site. I have my internal Microsoft tech reviewers open articles from a WSS site to review and comment on articles we are getting ready to publish. I think WSS is very cool, and I think it's even cooler that I can pull my WSS site into FrontPage and change the way it looks, add images, change text. The WSS site admin tool is okay for simple stuff, but with FrontPage, I can give my WSS site a whole other look. I can even change it so much that people don't know it's a WSS site.

The downside, IMHO, is that WSS is for intranets and extranets (although I have been told that it can be used with Internet sites as well). This in it self isn't a big issue, except that many of the features that require WSS are VERY COOL ... (and it's frustrating that I can't use them in my own Web site, unless I ask my ISP to install WSS, at which point they would surely groan at yet another server dependency to support, because I've already asked them to install FPSE and the .NET Framework, neither of which they've installed or configured correctly...) ... like WYSIWYG XSLT editing. From what I understand, FrontPage is the ONLY tool available for WYSIWYG XSLT editing ... but only within WSS sites, and then only within the XSLT Web part.

Problem #3: Dependencies

This deserves another mention. You see, the problems with FPSE dependencies are less an issue with FrontPage and more and issue with the FrontPage Server Extensions. Okay, I acknowledge that I generally like to leave the server stuff to someone else, but lately I've been working with FPSE, and all I can say is administering the FPSEs sucks ... and that's the polite version! It's not that it's so hard; it's just so confusing and frustrating and .... If all I had to do was apply the settings in the FPSE admin console, it would be fine, but there are OS settings, and IIS settings, and a host of other issues. I won't tell you the hoops I had to jump through in order get anonymous browsing to work on my 2003 machine. And depending on the OS that you have, you may need to configure different server settings.

Windows 2003 is locked down much more than 2000 or NT, so I'm sure the issues I encountered were different from those of many of our users, and I suppose the more you do it, the easier it becomes. I gained a new level of respect and admiration for server admins who have to administer FPSEs. My purpose in going through this pain? To understand what was wrong with the FPSE pages on MSDN. (They are the most widely visited and poorest rated pages in the FrontPage developer portal.) Yes, they are horrible, but I am working on it, and gradually, they should improve.

Feedback, even negative feedback, is a wonderful thing ...

Introduction

lisawoll — Thu, 15 Apr 2004 01:18:00 GMT

First, let me introduce myself. My name is Lisa Wollin, and I'm the programmer writer for FrontPage. Okay, so what's that? Basically, I write (and coordinate) the developer documentation for FrontPage, which includes beginning to hard core Web development, extending the FrontPage application, and the VBA language reference content in the box.

Well, now that the formalities are out of the way, let me tell you a bit about why I decided to do a blog. Before I get started, let me tell you a secret. Sh, you can't tell anyone. I've never liked FrontPage. My HTML editor of choice has always been … well ... something else. My beefs with FrontPage are much the same as the beefs others have.

For starters, I never liked the way it messed up my code. Perhaps I'm a purist; perhaps I'm a control freak; perhaps I'm just too dang fussy, but when I write code, I want it to look the way I formatted it to look because I did it ON PURPOSE. When I put in a line break, I want a line break. When I DON’T put in a line break, I DON’T want a line break. Very simple, but FrontPage just didn't get it. This, of course, is a very simplistic view of what previous versions of FrontPage have done to code. I've heard of situations where FrontPage would delete whole portions of code that would then have to be rewritten. Argh!!

However, to the credit of FrontPage and the FrontPage development team, FrontPage was initially designed for non-coders, the average Joe or Jane who just wanted to setup a simple Web site without having to learn how to code. I have to admit to being one of those at one time in my career, and for the newbie, non-coder, FrontPage is great. It does the job, and it does it very well.

But as those newbies become better educated, as they learn HTML and start to write script, they become more savvy about what a Web editor should be and what they want a Web editor to do, and although FrontPage is growing up, it hasn't always met the bar. In fact, my own HTML editor of choice has been Notepad … or ... well ... something else. Not a great development environment, but it does the trick.

So why do I work with FrontPage instead of … something else? Good question. I'll tell you that story another time. For now, to return to my purpose in blogging … well, blogging is a way for me to talk to my customers and for them to talk to me. Tell me your coding beefs with FrontPage, talk to me about our developer content, oh, heck, complain about Microsoft, if you want. Although I can't promise I can fix your problem, I do promise to commiserate, and I will do my best to help you find solutions. (Oh, and don't forget to tell me which version you are using.)

Happy surfing...

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.