Chapter 14

Wrapping It All Up

One of the selling points of any portal system, SharePoint included, is that it can create a full Web application for you out of the box. Sure, you have to install it and configure it but, once you have done that, you have a full system up and running, complete with things such as blogs, wikis, and message boards. And this is definitely true with SharePoint. But what can be forgotten or overlooked is that SharePoint can be, and probably should be, a starting point for your Web application. This book's intent is to start with a preconfigured installation of SharePoint and show you how to customize the look and feel to meet business requirements (branding) and accessibility compliance. As a SharePoint developer, you need to understand what SharePoint is really good at and where it needs your help. This book aims at highlighting these things with regard to the interface design of your portal.

Out of the box, SharePoint does an okay job of providing an interface for your site. It is, after all, a portal package and, as such, should provide at least a skeleton for the sites you create. But accepting that is like accepting a new car without a radio. Or air conditioning. Or power steering. Or cruise control. And maybe that is okay for some people. After all, that car will get you from point A to point B, which is the basic requirement of a car. And, like the car, the initial shell will serve the underlying purpose of SharePoint as a Web portal. However, like the car comparison, you'll probably feel better about the ride if you upgrade. And, fortunately, SharePoint was built so that it can be fairly easily “upgraded” if you have the desire and knowledge. Buying this book is a pretty good indicator that you have the desire. After reading it, you will have the knowledge as well.

So what might be helpful now, possibly as a future reference in going forward in your own projects, is to have a summarized list of the ideas presented to this point so that you can make sure they get due consideration in the design aspect of the SharePoint sites you create. To this end, they will be organized as checkpoints (but will not necessarily follow the chapter order of this book) so that you can think through them in a linear fashion and maybe quantify the design aspects of your own projects.

Checkpoint 1: Basic Web Design

One of the first things to take into consideration when planning the design of your SharePoint site is that it is, first and foremost, a Web site. As such, it is susceptible to the same scrutiny and analysis that any Web site would be. For example:

  • Is this an Internet or intranet application?
  • If intranet, can you control the browsers that access the site (for example, does corporate policy force all users to have Internet Explorer version 7 installed)?
  • If Internet, have you decided what browsers and versions you will plan for? Have you thought about the proliferation of various browsers in the Internet community and how big of a hit you will take if you don't, say, plan for Safari? Or Opera? Or Firefox?
  • What resolution will you target? Will you try to keep a fixed-pixel design? Or a fluid approach?
  • Will you try to adhere to Web standards, which may prove difficult, or ignore them for the easy road?

To answer these types of questions, you probably will want to try to get as clear a picture as you can on what today's Internet user is using to access the Web. For example, if you want to know what browsers (and versions of those browsers) to target, what analysis could you use to make this decision? You probably couldn't look at your own site statistics, since this is the planning phase of a project and those statistics aren't available before the site is live. So what might be helpful are some generic Web statistics showing what the Web population as a whole (or at least a representative sample of that population) is using.

For this, you might want to consider using statistics like the ones located at TheCounter.com: http://www.thecounter.com/stats/. TheCounter.com provides analysis tools for Web masters that report on things such as the browsers, resolution, operating systems, and color depth used by the visitors to your site. This is handy, but what is exponentially more useful, at least for this discussion, is that they also aggregate the data monthly and report the global statistics for free to anyone interested. This gives you a much better idea of what is going on in the world of Web surfing. And the price is right.

Of course, if you are targeting your own intranet, this might not be such a big deal. If, for example, you have a corporate network policy that pushes out the latest version of Internet Explorer to all users and you have official protocol that establishes that all employees and visitors to the intranet must use this version, you might not have as big of a need to analyze Web trends for determining browser targets. However, this could backfire on you as well. What if a high-ranking senior staffer uses Firefox even with that policy in place? Are you really going to say, “Well, the company policy requires Internet Explorer, so we're not going to fix the site for you”? Probably not. And believe that, with few exceptions, policies like these don't force people to use the browser you want them to use. People will use what they want.

But remember, these are just the general Web design considerations. In SharePoint, there is always the extra rub that the site is, in fact, also a SharePoint site. So you have to go a bit further than just the basics.

For example, you need to also take into account the level of security you want for your site. Do you want to use Windows-based authentication and tap into an already existing Active Directory system? Or do you want to just use the SQL Membership Provider with forms-based authentication provided as part of the ASP.NET 2.0 Membership Provider? Or maybe a third-party option? Security will definitely be something to consider in the general Web design discussions, since every SharePoint site will have to have some level of security implemented, even if it is planned to be an anonymous Web portal (allowing un-authenticated user access). After all, you have to have some way to administer the site's content, and without security how would you do that? So some discussion about the security ramifications would need to be had, particularly in regard to the way SharePoint uses security.

You will also need to delve into which type of site you want to create. Most companies use SharePoint for one of two purposes: to collaborate with a group of folks or to communicate to them. The distinction between these two types of sites is the number of directions the communication flow of information goes. If it is one-way (from the corporation to all interested parties), it is a communication site and should therefore utilize the MOSS 2007 publishing site templates. If the communication flow is bi-directional (or even multi-directional), where the company is communicating back and forth with interested parties, the site has a more collaborative focus and should use one of the MOSS 2007 collaboration templates. So it is important to understand who your audience is and how they will interact with the contents of the site so that you can make an informed decision as to what type of site you want to create for your portal.

Related to this concept is the topology for the hierarchy of the information you plan to present to the patrons of your site. In other words, how do you want to structure your information? This has a direct result on things such as navigation, since you need to know where the logical breakpoints of your information are and then determine the subsets under each. For example, in a business-based model, you could decide the major categories are areas within your organization, such as Accounting, Marketing, Human Resources, and Information Technology. Then, under each of these classifications, you would have logical subunits of information, such as Accounts Receivable under Accounting and Benefits under Human Resources. Conversely, in a taxonomy-based model, your major headings would be classifications, such as Production or Research & Development with subgroups like Vendors and Factories for Production and Projects and Patents for Research & Development. While this will certainly play a much larger part in the navigation structure of your site (as is discussed later in “Checkpoint 8: Intuitive Navigation”), it is good to start talking about it here as well, as it helps define what the site is and why you are creating it.

If you want to read more about these concepts, they were discussed in more detail in Chapters 2 (“Web Design 101”) and 4 (“Communicating or Collaborating?”).

Checkpoint 2: Accessibility

Arguably, accessibility could be wrapped up in Checkpoint 1, since it is, in all honestly, a part of general Web design concepts. And, a few years ago, it probably would have been (if it was included at all). But times are changing and accessibility is becoming an increasingly important discussion point for creating Web designs today.

You can see this all around you if you look closely enough. Historically, Internet Explorer metaphorically stuck its nose up at Web standards. If you don't think this is true, try to create a site that is standards-compliant (heavily CSS) and load it in a more standards-based browser like Firefox. Then try to load it in older versions of Internet Explorer. Oh, and by older, that doesn't mean versions and versions ago. No, try loading it in Internet Explorer 6, which still has the major market share in Web browser hits today. It breaks. Almost inevitably, it breaks. But look now at the latest release, Internet Explorer 7. It is much closer to the other standards-based browsers on the market. And the next version, 8, promises to be even better.

You can also see this trend in some of the information presented in this book. Microsoft engaged a research group to identify exactly how important assistive technology is for today's Web surfer and had some eye-opening results. This might have been what led to a lot of the progress seen in recent years, including, but not limited to, Microsoft's partnering with the community to create the CSS Friendly Control Adapters and the Accessibility Kit for SharePoint in the last few years. As the giants begin embracing this vantage point, you can guarantee it will filter down over the years. Although, honestly, much of the accessibility buzz started at the grassroots level and just worked its way up. But as the above-the-fold companies like Microsoft are embracing it, you know you are at a turning point.

And it's not strictly philanthropic. There are definite business reasons to consider in your reasoning. If not for the hundreds of billions of dollars estimated for discretionary income of the disabled, then for the emergence of litigation for noncompliance. While not widespread yet, if it happens to you, it is widespread enough. And if it can touch companies like Target, it can touch you, too.

So as you start planning your site, it is important to ask, “Is accessibility right for this site?” In every situation, hopefully the answer is “yes.” And if it is, you have to decide which level of compliance to hold yourself to.

As you saw in Chapter 13, there are three priority levels of compliance for accessibility. Priority 1 is for all the things that every site has to do and is the bare minimum standard for compliance. Priority 2 includes additional items that every Web site should do. And Priority 3 is more of the nice-to-have features (at least for now). If trends continue the way they are, it won't be surprising to see a lot of Priority 3 items jumping up to 1 or 2. But, for now, they are not the ones that will get you in trouble. So, using this classification schema, all sites should be held to Priority 2 compliance. Again, these are the things that all sites should do, which includes Priority 1, which is all the things sites must do.

So where does SharePoint fall? Priority 3? Priority 2? Priority 1? Unfortunately, out of the box, SharePoint doesn't even accomplish Priority 1 compliance.

This is not a doomsday sentence, though. This is just an awareness exercise. Consider it a challenge. With enough planning and work, you can surely bring your site to at least Priority 1 and maybe even Priority 2.

Take, for example, the Priority 2 checkpoint of not using tables for layout (only for tabular data, like data grids). This fails all over the place, starting with the basic layout of the page for SharePoint sites, which uses tables. But you can fix that by deciding to create your own standards-based master pages (discussed more in Checkpoint 5) and deciding to use CSS rules to lay out your page rather than tables. You can also implement the aforementioned CSS Friendly Control Adapters (as well as the adapters included in the Accessibility Kit for SharePoint) to override the rendered controls to output CSS rules rather than tables for things like navigation and even blog entries.

The important thing is to understand the limitations you are up against and decide you are going to overcome them. You have to decide to make accessibility a priority and then figure out the tools you need to make that happen.

To read more about accessibility, as well as the CSS Friendly Control Adapters and the Accessibility Kit for SharePoint, turn to Chapter 13 (“Accessibility in SharePoint”).

Checkpoint 3: The Design

At this point, you have figured out what type of site you want, what kind of content you are going to provide, and what kind of Web considerations you need to incorporate into the design of your portal. With that information, it's time to mock up the design for your site.

The biggest point to this is: Get inspired. Don't even look at the standard SharePoint templates and sites. You don't really want people thinking, “I've seen that site before. A lot.”

Go out and see some really great examples of what other people are doing in SharePoint. Or, even better, go out and see what other people are doing in Web design and see what you can bring back to your own site. Sure, there are limitations for design in SharePoint. It is, after all, a portal. And, as such, there is a need for some basic elements such as navigation, search boxes, and, of course, content. So if you go to a really nice Flash-based site featuring the photographic talents of an artist in the San Fernando Valley, is that going to port directly to a SharePoint site? No, probably not. But can you get some ideas on it? Of course. Maybe the background grabs your attention. Or maybe the layout of the header makes you smile. You can take pieces of that thought and integrate them into your own site.

So maybe search the Web for a while and find some really good sites. Bookmark them. Print them out. Think about what you like about them and what you can use for your own site. Write on the printouts or use some sticky pads. Really put a concerted effort into coming up with the good stuff and the reusable stuff.

Maybe even go to Web sites that have articles on proper Web design. A good site for things like this is Smashing Magazine: http://www.smashingmagazine.com. This site is dedicated to providing free commentary on today's Web design. For example, in April 2008, they published the article “Web Form Design: Modern Solutions and Creative Ideas” to showcase different HTML forms and how different designers approached the task of using these forms in their sites. This ranged from clean and elegant to creative and interesting. They also included tips in this article on how to approach something like the standard “Contact Us” form. While this article may not be directly relevant to your project, it certainly can give you some good ideas (and some potential example sites to check out).

Now that you have some ideas of what your site should be, you might consider whiteboarding it to see if you can make everything flow. Sort of lay out, either with pen and paper or, quite literally, on a whiteboard, all of the elements you want to integrate into your site. Maybe cut out some of the examples you printed and stick them in the relevant area of your manual mockup. Try to materialize the intangible idea into something more solid; something you can create in HTML.

Finally, once you've thought about it, get out your graphic editor program and get to work. In this book, this was done using Adobe Photoshop CS3, since that is one of the most common tools for creating Web graphic mockups. But it is certainly not the only tool. In fact, there are some great free resources out there if your means are limited. One popular free graphics program is the GNU Image Manipulation Program (GIMP): http://www.gimp.org. GIMP is fairly similar to Photoshop except that it is completely free and open-source. Their Web site contains the free download as well as a slew of free tutorials and documentation. If you don't have the means to get into Photoshop, this is a very viable solution.

So, with your graphic editing program of choice, integrate the planning you have done for your Web site (including things like target resolution) and the visual inspiration you have garnered to this point and make something worth showing off. Create a design that you are proud of and that you would gladly include in your portfolio. Make sure that you include the required elements (such as the navigation and search area), but don't restrict yourself to the portal design of the header and attached navigation with the sidebar and the footer that you see everywhere. Or, at least if you do, make it look special. Make it look so little like standard SharePoint that people need to go into the rendered code of your site to see that it is SharePoint.

To get an idea of how to create your own portal design, you can read Chapter 3, “General Concept Design.”

Checkpoint 4: Creating the Mockup

It's finally time to start writing some code. You have all of your planning done and you have made all of your decisions as to what the site will be, who it will serve, and what information will be consumed. You have worked diligently to make your site look as good as possible and have created a reasonable mockup in a graphics editor program. You're probably itching to get some code down and it's finally time to do exactly that.

The next step would be to create the HTML equivalent to the mockup you created in, say, Photoshop. Hopefully, you have decided that you are going to shoot for some level of accessibility compliance and, as such, this means you are going to use CSS. And this is, to be honest, the hardest part of this section.

While CSS isn't the hardest concept in Web design to learn, it also isn't the easiest. In fact, for some developers, its steep learning curve can cause anxiety. But, as accessibility keeps garnering more and more attention (and more and more consequences for noncompliance), CSS will become the standard for which it was created.

But for now, it can prove difficult (especially when having to control position and float elements, as you saw earlier in this book). There is the annoyance that CSS can work differently in different browsers. Your header is positioned perfectly in one, scrunched up in another, and completely out of position in another. So, when you introduce CSS into your design, you introduce another potential fail point.

But it's worth it. The design will load faster and be much more accessible to those who need it to be. It will separate design from code, which is the premise of things like n-tier architecture, and provide a universally central location for style rules that all developers in a project can use.

It makes sense to use CSS. It makes sense on a financial level with the accessibility arguments raised earlier. It makes sense on a performance level because CSS files are cached and only have to load once, which makes pages load faster. And it makes sense on a productivity/reusability level since developers can share the style rules across teams and keep a consistent look and feel for all of the pages.

It makes sense. But it isn't always easy. It will be a struggle if you are new to CSS as a design tool. But it will be worth it in the end.

So, with that in mind, you should begin creating a static HTML page with an external CSS Stylesheet that creates the basic layout of your site. You can use your graphic editing program to create the images you will need for the layout and then position them with the CSS rules that are called in your HTML page.

You will also want to validate (and re-validate) your HTML code throughout the process. You can use tools integrated within the Internet Explorer Developer Toolbar and Firebug (both discussed in Chapter 7) to help you do this. There are also several HTML and CSS validation sites out there that will allow you to enter in your code to see if it validates against universal Web standards, such as the W3C markup validation service, located here: http://validator.w3.org/.

At the end of this process, you should have a static HTML page that will load in the major browsers (at least Internet Explorer, Firefox, Opera, and Safari) and look the same in each. It should be have passed at least some level of CSS and HTML validation and be, say, Priority 2 compliant.

The physical files that you will end this checkpoint with are an HTML page, and external Stylesheet, and several image files.

To read about how to work with creating your HTML/CSS mockup, you can go through Chapter 7 (“Cascading Style Sheets with MOSS 2007”).

Checkpoint 5: Creating the Master Page

Now that you have a basic shell for your site, it's time to bring it into the world of SharePoint and create a master page wrapper for your code.

Master pages were introduced as part of the .NET 2.0 Framework and allowed for templating of your ASPX pages. Essentially, a master page creates the shared format of your pages and creates content placeholders for you to use to inject to specific content of any given page into the master page shell. So, this generally means that you create your header, navigation, sidebar, and footer in your master page and then create a placeholder where you want all of the content to go. Then, on any page in your site, you would inherit this master page and throw the content for that page in the provided placeholder. So if, for example, you had a GridView control with the entire inventory for store ABC, you would just inherit the master page, which brings all of the header, footer, and related pieces in, and then add the GridView control to the content placeholder set up by the master page.

And, since SharePoint is built on the .NET 2.0 Framework, it allows for the use of master pages. However, there is a catch. SharePoint requires more than one content placeholder. It requires more like 20 content placeholders. And, if you miss one, you will probably see errors in your rendered pages. So you have to be careful. There are also considerations for where these content placeholders are placed. For example, if you place the “PlaceHolderTitleBreadcrumb” content placeholder in the footer area, it's going to look pretty weird. And with things like page edit mode, placement can get even trickier.

However, if you have set up your HTML mockup soundly, this step shouldn't go that badly. You know where the “PlaceHolderTitleBreadcrumb” will go because, well, you mocked it up beforehand and you will have a pretty good idea where you want the breadcrumb to be located. So, with proper planning in checkpoints 1 through 5, this should go fairly smoothly.

However, it is important to remember that the master page in SharePoint is not a physical file that you can store in a virtual directory. It is a file that is built on the fly from configuration files and database records (everything is virtual). So this means that you will also have to get into SharePoint designer, if you haven't already, to begin creating your file. You will also have to take into consideration the default master page and overriding of the standard site definition of the files you touch.

However, once you have created a SharePoint master page for the first time, all subsequent times seem relatively easy. Like most things in technology, the first time is the hardest.

You can read more about creating SharePoint master pages by going through Chapter 8 (“Master Pages”). Additionally, you may find it useful to read more about using SharePoint Designer in Chapter 5 (“Introduction to SharePoint Designer”).

Checkpoint 6: Using a Theme

Another concept introduced in the .NET 2.0 Framework was the idea of themes. Themes allow developers/designers to create skin files that can set defaults for much of the content of a given Web site. For example, a developer could create a skin file that would make every GridView control added to the site have a black header row with a white bold font and then alternating gray and white rows thereafter. With this skin file in place, all any developer on this project would have to do is drop a standard GridView control onto their page and it would automatically be formatted for them. This allows for a really easy way of binding the look and feel of the content of your pages to ensure that all pages are consistent with the prearranged look of your site.

But, beyond that, you also get the power to set up any of the other properties of the controls in your skin file. If, for example, you want all GridView controls to allow pagination and to show 10 records per page, then you can do that in the skin file. So when a developer drops a GridView control on their page, this setting is already made for her behind the scenes. Now, if the business rules require it, the developer can override these defaults and set the properties directly on the control itself. But the fact that she can have preset defaults for any property on the control you want is pretty exciting. This truly allows for consistency among all pages of a site.

While SharePoint themes are essentially the same as ASP.NET 2.0 themes (they are, after all, built off of the ASP.NET 2.0 themes), there are some additional considerations to take into effect. For one, they are applied differently through the site settings of your SharePoint site and require some extra files to work (the theme .INF file, for example). They are also stored in a different location than a typical ASP.NET 2.0 theme, which also introduces potentially new hurdles like sharing themes among server farms.

You can read more about how to set up and apply your SharePoint themes in Chapter 6 (“Themes”).

Checkpoint 7: Considering Page Layouts

Especially if you have decided your site should be a Publishing site, you will want to seriously consider creating and integrating page layouts into your Web design schema.

Page layouts actually work hand-in-hand with master pages. In fact, from a very high level, page layouts almost resemble the concept of nesting master pages, which is fairly common in ASP.NET applications.

In a master page, you decide the basic look and feel for all pages in your site. For example, you might have the standard header and navigation at the top, a footer area at the bottom, and the center is basically left wide open for content.

A page layout then comes along and says, “Okay, that's fine, but there will be several different formats for content in that area.” For example, you might have one type of page that you would classify as the “welcome” page. You might have another that you would classify as the “articles page.” And you might have still another page that you would use for grids of data. While all three types of pages use the basic formatting and layout of the master page, the content for each will be laid out differently. Page layouts allow this distinction between pages that use the master page. Additionally, they define the editable data for different types of pages.

And the really nice thing about page layouts is that they allow for reuse throughout the project. This means that once you create a new page layout other developers can then use that page layout as the template for a new page. So if, for example, you created a page layout for “articles” pages, a developer could then use that page layout to create a new “articles” page for a site he was working on. This allows for better continuity between the sites of your SharePoint portal.

To read more about page layouts, you can flip back to Chapter 9 (“Page Layouts”).

Checkpoint 8: Intuitive Navigation

Like a lot of other things pointed out so far in this chapter, life got much simpler for Web developers in respect to navigation with the release of the .NET 2.0 Framework. All of a sudden, navigation became intuitive and easy to implement with the use of standard navigation controls and sitemap datasources, which were typically either XML files or database connections. You could set up globalization as well as security simply by modifying some files in your Web.config (and maybe setting up some resource files). Typically speaking, you could create a very solid navigation schema simply by detailing your site hierarchy in a sitemap XML file and then connecting it to a standard menu control on, say, your master page.

And again, like several other topics in this chapter, SharePoint reaped the benefits of this advancement since it, too, was built on the .NET 2.0 Framework. But, just like those other benefits, integration with the SharePoint environment added a new level of complexity.

First, it matters if you are using a WSS 3.0 or a MOSS 2007 site. Strangely enough, this affects your navigation planning since WSS only offers a subset of the functionality offered in the full MOSS version. Additionally, the idea of an XML sitemap data source is lost on navigation like the Top Link Bar where all navigation, including the order in which the tabs appear, is set through the SharePoint interface. There are also, typically speaking, several navigation controls for a single page. For example, there will almost always be a Top Link navigation bar near the top of the page, but there will also often times be a Quick Launch navigation bar on the left-hand side of the content area. Just by the fact that one of these is typically horizontally aligned and the other one is vertical, you are probably going to need to design these differently.

And while you are looking at all of the properties for styling these controls, you run into one other hurdle: They render tables in your final HTML. This means that, if you use the out-of-the-box navigation provided with SharePoint, you can't achieve Priority 2 accessibility compliance. So what do you do? This brings the CSS Friendly Control Adapters back into the planning. You can integrate these adapters to override the rendering behavior of the navigation controls to render out more accessible code (for instance, DIV, UL, and LI elements as opposed to tables) and continue working toward achieving Priority 2 compliance.

You can read more about navigation considerations in Chapter 11 (“Navigation”). You can also see an example of how to integrate the navigation control overrides of the CSS Friendly Control Adapters in Chapter 13 (“Accessibility in SharePoint”).

Checkpoint 9: Content Considerations

While you have certainly, at this point in the checkpoints, given some consideration to the content area of your portal through things like page layouts and themes, it's time to really hammer down on what your site needs to provide to be successful, and the design considerations for these elements.

One of the main elements to consider is the search functionality of your site. Search is probably one of the most sought-after features when considering implementing SharePoint. It is powerful and fairly easy to modify and customize if you know what you are doing. And, as part of this customization, you can style the results to fit along with your site.

Additionally, since most content of a SharePoint site is delivered through Web Parts in some form or another, it is critical that you have a solid understanding of at least some of the major Web Parts available with a standard installation and how they can be used in your own sites. You can then use these Web Parts strategically in your content areas to allow users to provide the information for your site, as well as maybe sneak in a little JavaScript functionality to help make your site a little better. You can even use these Web Parts to bring in data from unrelated sites to add more value to the users that consume the content of your portal.

While most of the other areas of the book were talking about how to style components of a SharePoint portal to integrate with your design, the chapters on Web Parts were more aimed at making sure you were aware of some of the Web Parts you could integrate into your content areas as part of the design of your site. In other words, when planning out how your site will look, you can decide which Web Parts to include and where, to facilitate this design best.

You can read more about styling your search results, as well as the Search Web Part, in Chapter 12 (“Customizing Search”). You might also want to read Chapter 10 (“Working with Out-of-the-Box Web Parts”) to help you better plan the Web Parts to use in creating the content areas of your final portal design.

Checkpoint 10: Checks and Validation

Now that your site is set up, you can sit back and admire your work, right? The site looks cutting edge and maximizes the controls and features of SharePoint to create content worth talking about. Everything is laid out perfectly and intuitively and you are ready to pass it on to your users.

Or are you?

If you really wait to test until Checkpoint 10, you are going to probably regret it. Hopefully, as you implement new design aspects to your site, you are testing them along the way. However, as a final step, you should recheck everything.

What does this mean?

Well, to start with, it means testing in as many popular browsers as you can. This would probably include, at a minimum:

If you have it available to you, you should also test against Microsoft Internet Explorer version 6 since it is still one of the most popular Web browsers. In fact, according to the statistics at TheCounter.com, IE6 continually beat IE7 until February 2008 and, even through March 2008, was still running almost neck-and-neck with the more advanced browser. So it makes a lot of sense to keep testing with IE6 until it is no longer accessing pages on the Internet, which will probably not be anytime real soon.

Is that enough? Well, it depends. But, generally speaking, the answer is probably “no.”

What about mobile devices? Will your portal ever be accessed by mobile devices? If so, have you tested to see how it works? While this might seem hard to test with, there are emulators you can download for pretty much any mobile operating system to test against and run from within Visual Studio. This includes Palm, Blackberry, and, of course, Windows Mobile.

Is that enough? Well, again, it depends. And, again, the answer is probably “no.”

Why not consider testing your application against one of the most popular assistive technology browsers, JAWS (http://www.freedomscientific.com/fs_downloads/jaws.asp). While the full version costs money, there is a free demonstration version you can download that will work in a limited capacity and will let you know pretty quickly how your site sounds. (JAWS actually reads out all of the content of your site from your browser.)

And of course, you should give some consideration to validation just to make sure you didn't miss anything. Some popular validators would include:

If everything looks okay in all of the listed browsers, sounds okay in JAWS, and passes the validation tests, you are probably okay. But if you change anything along the way, you should retest against all of these tools.

In fact, go ahead and retest anyway. You can never be too safe.

Summary

So, as the final chapter wraps up, what have you learned so far?

Hopefully you learned that the standard SharePoint installation is just a starting point for your design, not a finished product. You saw in this book how to use various tools, many of which came with the introduction of the .NET 2.0 Framework, to customize the look and feel of your site while at the same time keeping that look and feel consistent across all pages. You also saw how just because something worked one way in a standard ASP.NET page doesn't mean it will work the same way in SharePoint. In fact, it probably won't.

But more basic than that, hopefully you got to a point where you are thinking about SharePoint, at least in a designer's eye, as simply being some HTML that is there for you to manipulate. You can now see it as a Web site, not a portal. And a Web site you can design; portals are what seem hard.

And, in this chapter, hopefully you gained a bigger picture of how all of these concepts come together. In fact, you could almost take this chapter and use it as your own checklist for the SharePoint sites you develop. Will it be exhaustive? Of course not. Every project has its own nuances that must be considered as part of the planning phase. But this is a good place to jump off from. And that should be the point of any good programmer's book—helping you take the leap into something new. As this book comes to an end, we hope we have provided that for you.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.82.21