Users can insert a table into their presentation, then easily add, select, and resize rows and columns, format and align text across the table, and set background colors for cells and borders. Rows will resize themselves to fit content.  Google provides the following example table:

Collaborators on presentations can make edits to the same table at the same time. When tables are imported from PowerPoint, they’ll show up as editable tables in Google Docs.

To use the Table tool, simply choose "Table" in the presentation editor. Then click "insert table." Select the dimensions. At that point, it will appear and you can start editing it.

To add rows and columns Google provides the following instructions:

1. Point your mouse to the outside borders of the table and a ‘+’ sign and an arrow appear.

2. Click the ‘+’ sign to add a row or column. The signs appear on both ends of a row or column, depending on which side of the cell your mouse is closer to. This determines where the row or column is added.

3. If you click the ‘+’ sign at the top of a column, another column appears. If you click the ‘+’ sign next to a row, another row appears.

To Select Cells:

-   Select an entire row or column: Point your mouse to the outside borders of the table and a ‘+’ sign and an arrow appear. Click the arrow to select a row or column. If you point your mouse to a column, you’ll select the column. If you point your mouse to a row, you’ll select the row.

- Select a range of cells: Drag your mouse from one cell to another to select multiple cells. To select a single cell, drag the mouse out of that cell and back into it.

Once you’ve selected cells, you can apply formatting changes to all of them at once by pressing the delete key. More info on adding and editing tables can be found here.

"Fusion Tables is not a traditional database system focusing on complicated SQL queries and transaction processing," Google’s Alon Halevy and Rebecca Shapley explain. "Instead, the focus is on fusing data management and collaboration: merging multiple data sources, discussion of the data, querying, visualization, and Web publishing. We plan to iteratively add new features to the systems as we get feedback from users."

With Fusion Tables, users can upload tabular data sets and share them with collaborators or with the general public. You can choose which data to share, and keep certain parts hidden if you wish. You also have control over which collaborators see certain parts of data.

Filters and aggregation can be applied to data, and it can be visualized on maps and other charts. Data can be merged from multiple tables, and it can be exported to the web or csv files. Discussions can also be conducted at the row, table, and individual cell levels.

 

As with Google Labs in general, you have to take into consideration that Fusion Tables is in the experimental stage. This means that there are probably some bugs and some things missing. Google is encouraging feedback, and perhaps eventually, it will work its way out of Labs and into the full-blown product stage.

See screenshots of some applications that have ReportViewer control embedded in them.

The ReportViewer control offers the following benefits:

• Processes data efficiently. The reporting engine built into ReportViewer can perform operations such as filtering, sorting, grouping and aggregation.
• Supports a variety of ways in which to present data. You can present data as lists, tables, charts and matrices (also known as crosstabs.)
• Adds visual appeal. You can specify fonts, colors, border styles, background images etc to make your report visually appealing.
• Enables interactivity in reports. You can have collapsible sections, document map, bookmarks, interactive sorting etc in your report.
• Supports conditional formatting. You can embed expressions in the report to change display style dynamically based on data values.
• Supports printing and print preview.
• Supports export to Excel and PDF.

The control can process and render reports independently using a built-in engine (‘local mode’) or it can display reports that are processed and rendered on a Report Server (‘remote mode’). There is also a WinForms and a WebForms version of the control.

Report design in a nutshell

• Defining report data sources.
• Using object data sources in Windows applications and Web sites.
• Using Lists.
• Adding Tables to your report.
• Designing Matrix (crosstab) reports.
• Using report parameters in local mode.
• Designing master-detail reports.
• More topics coming soon!

See more at: http://www.gotreportviewer.com/

Comments

Tag:

Add to Del.icio.us | Digg | Yahoo! My Web | Furl

Kenny and .NET” blog.

However there have been very few articles looking at things from the other side of the fence. This is probably because you really have to understand and use CSS based design before you can criticise it. Yet once converted, few (if any) people go back to the old way of coding.

In order to bring some balance back to the equation, and to have a bit of fun playing devils advocate, I’ve decided to write an article about why in some instances, traditional table based design can be as good, if not better than CSS and standards based design.

The Demonisation of Tables

Before tables came along, the web was a pretty dull place. Using tables for layout opened up the possibility of visually “designing” a page. It could be argued that table based layout was responsible for the popularity of the web and the field of web design. That’s right. Without tables, all us web designers would probably be without a job.

Yet over the last few years, table based layout has become demonised. Web purists will tell you that tables were never meant for layout so you shouldn’t use them for such. However history has shown us many examples of technologies that started out life with one purpose, only to ended up finding more practical applications as something else. The web itself was never intended to be anything other than a way of sharing research data, and yet it’s become a channel for entertainment and marketing as well as information and education.

The Comfort Factor

As web designers, we’ve been laying out pages using tables for years. It’s a skill most web designers have, and most are comfortable with. Using tables in this way leads to very predictable results. By using a few very simple hacks, such as spacer gifs, we can pretty much guarantee that our sites will look the same on the widest range of web browsers out there, from the lowliest version of Netscape 4 to modern browsers such as Safari.

Despite the fact that pioneers have been talking about web standards for a long time, the majority of web sites are still developed using tables and non standards compliant code. Because of this, user agents will be forced to handle table based layouts for many years to come. This effectively negates one of the biggest selling points for web standards. That of forward compatibility. It’s highly unlikely that in the near future, any of the big browser manufacturers (um, that’ll be Microsoft then) will release a browser that renders the majority of sites unusable.

So most web designers really don’t feel there is an overwhelming need to start developing sites using CSS based layouts and standards compliant code.

Changing the Barriers to Entry

One of the reasons the web has been so successful, is it’s low barrier to entry. HTML is a simple “language” to learn and browsers are very forgiving about poorly formed documents. This makes it incredibly easy for anybody to publish on the web. Even your 12 year old nephew could knock up a simple site using the copy of Frontpage that comes bundled with Microsoft Office.

Compare table based design to CSS based design. Sure the syntax of CSS is pretty easy. Nobody in their right mind would argue that you need too be a rocket scientist to learn CSS. However, some of the concepts can be quite tricky to grasp. On the face of it, the box model is pretty simple, yet I still get tripped up by margin collapsing on occasion. Floating and clearing can be conceptually difficult to grasp, as can positioning. In my experience, there is probably around a 6-12 month learning curve from knowing basic CSS to actually being able to develop CSS based sites competently.

Then there is the problem of browser support. Once you’ve been doing it for a while, you get to know what browsers support what, and what the common browser bugs are. However, there are so many bugs, even the “experts” find themselves spending an inordinate amount of time bug fixing. For a novice this must be extremely frustrating. Not knowing if the problem is down to your misunderstanding of CSS or some obscure browser bug. Is it any wonder why the same questions come up time and again on list like CSS-Discuss?

When the browser manufacturers finally get their act together, developing sites using CSS will get a lot easier. Still, I think most people would agree that CSS development has a much higher barrier to entry than table based design. In an odd way, I think this is one reason why CSS based design is becoming so “popular” amongst web professionals. It allows them to differentiate themselves from the amateur “FrontPage Cowboys” and take back the web for themselves. Perhaps this is why many people see web standards as “Ivory Tower” and why many web standards advocates come across as having a sense of superiority and a zealous attitude towards web design.

Some Things Are Just Easier with Tables

I’m sure we’ve all found ourselves writing fairly complicated CSS to do something that would be trivial using tables. Take form styling for example. It’s possible to lay out even very tricky forms using tables in just a few minutes. You can achieve similar results by floating elements with CSS, but it’s a lot more involved. |f you’re a CSS guru it’s all part of the fun. However if you’re a regular mortal and your boss is breathing down your neck because they don’t understand why their “simple form” is taking so long, it can be incredibly frustrating.

If you have the knowledge and patience, you can do most things using CSS that you used to do using tables. Sure it may take you longer, but you’ll get there in the end (or die trying). However there are some things which, try as you might, you just can’t seem to crack. One such thing is page footers. I regularly see posts from frustrated CSS authors trying to create page footers than “stick” to the bottom of the viewport if the content doesn’t fill the whole screen. It’s pretty easy to do using tables, but try doing this using CSS alone. Is it any wonder why web developers turn their back on CSS when even simple things are rendered so complicated when you stop using tables.

Overstating the Benefits

There are lot’s of good reasons for throwing away tables and adopting CSS based layouts instead. However in their rush to push web standards, many people have overstated the benefits. It’s true that switching a large site to a CSS based layout can save a huge amount of bandwidth. However, for most sites, this saving would be insignificant.

People want fast loading pages and many advocates have suggested that CSS helps accomplish this. For most sites, the “design” is spread evenly across the whole site. However with CSS based sites, the “design” is usually held in one or more external files. These files can be pretty complicated, and even for a simple site, can get big, fast. A recent site I designed uses 4 stylesheets weighing in at around 12k (albeit including formatting and comments). By using CSS you’re actually front loading the design, rather than spreading it evenly across the site. The means that the first page you hit can actually take longer to download than the equivalent table based page. Once the styles have been downloaded, they will usually be cached and not need downloading again. However the first page on a site is the one page that you really don’t want to see such a performance hit.

Client buy-in

The sad fact is, most clients don’t care how a site is coded. Yet for some reason web designers feel the need to “sell” web standards to their clients. One way people do this is through the carrot and stick approach. The carrot is more often than not, search engine friendliness, while the stick is accessibility.

It’s true that the search engines like semantic pages. It’s also a widely held belief that search engines like lean code. Building a site using CSS and web standards can definitely encourage the development of search engine friendly sites. However it’s no magic bullet. There are many table based sites out there that score very highly in the search engines. It’s equally possible to build a CSS based site that gets a terrible search engine ranking. The most important thing for high ranking is content and inbound links, not whether a site uses tables or CSS for layout.

More concerning is the number of people who try to sell web standards and especially CSS based design by playing on clients accessibility fears. There isn’t anything inherently inaccessible about table based design. As long as tables make sense when linearized, their content is easily accessible. Screen reader technology is pretty good these days, and most screen readers are proficient at handling table based sites. While it’s true that your site needs to be published to a recognised set of grammars to get a AA accessibility rating, tableless design is only a recommendation, not a requirement for the more stringent AAA rating.

One often mentioned benefit is that of supplier independence. In a world were everybody develops to a standard, it would be much easier to switch between developers. They’ll instantly understand how the site was put together and not have to trawl through somebody else’s tag soup. This is reliant on having a significant number of suppliers versed in web standards. Unfortunately this currently isn’t the case. While the number of skilled CSS developers is increasing, it’s still a relatively specialist field. Because of this, it could be seen as a relatively risky proposition for a large company to lock themselves into a style of coding when there is such a lack of skilled coders. In my experience an organisation will often have a single individual experienced enough to develop a site using CSS. For many organisation switching to web standards could actually increase their dependancy rather than decrease it.

Conclusion

Web standards and CSS based design are definitely the way forward. However in our rush to advocate these “new” techniques, we may end up believing our own hyperbole. Build something up enough and the reality will always fall short of our expectations. By taking a dogmatic approach we risk alienating the very people we are trying to convince.

Table based design will be around for a long time. To encourage developer buy-in we need to lead by example and help reduce the barriers to entry. Not create new barriers. We need to be honest and up-front about the benefits as well as the cost. Developing CSS sites can be hard and it can time consuming. In certain circumstances using tables for layout can make much more sense than CSS.

Andy Budd is the author of the book CSS Mastery. Its currently one of the top 5 best selling web development books on Amazon.

http://www.andybudd.com/

CSS purists all over the web have been promoting the idea that tables are bad for so long now that some people think they’re breaking the law or worse if they use a <table> tag in their website.

Well, I’ve got news for them – you are still allowed to use tables!

Tables vs CSS

This is not a css vs tables rant, and I am certainly not advocating a return to the nested table and spacer gif nightmare of years gone by, just a plea for common sense. A lot of people seem to think you have to use one or the other, but in fact CSS and tables can be used together.

Much of the effort put into designing css only layouts involves using the “float” property to produce columns. While that is simple enough to achieve on a basic level, coming up with a method that produces equal height columns no matter which has the most content, where the footer stays below the columns, and which works correctly across all browsers has taxed experts for years.

People are still coming up with new variations using all sorts of esoteric methods and hacks, such as negative margins, to do what a simple table has always been able to do.

Tabular Data

It is often said that tables were designed for presenting tabular data only and shouldn’t be used for anything else. Well, its been said before – the world is full of things which were originally designed for one purpose, but which people found could be used for an entirely different purpose. The internet was designed for sharing scientific data – does that mean we shouldn’t use it for anything else?

In any case – what is data? If you ask me, data might be something like a product picture, description, price, “buy now” button, or menu, article, advertisement. Tabular data is surely data in which there is a unique relationship between one set of data and another e.g. all the data on one row refers to a particular product. Again, that surely could include price, description, picture, etc.

Block Level Elements

HTML consists mainly of block level elements and inline elements. Block level elements are containers or boxes that start and end with a new line, such as a paragraph, table or a div. Inline elements can be placed in the middle of a line of text – such as bold or italic (although elements can be changed from inline to block and vice-versa with CSS).

A <div> is the name given to a generic container, a single box. A <table> is the name given to a box which is divided into rows and columns. It seems to me that if you want a part of your website divided into columns, it makes more sense to use the element which is meant to be divided into columns, the TABLE, rather than trying to construct a series of columns out of separate containers (DIVs)If you want to connstuct

Search Engine Friendly?

It has been said that CSS layouts are more search engine friendly and are leaner and quicker to download. While this is certainly true when compared to old-style nested table layouts, it is not necessarily the case – table layouts with external style sheets for styling can be just as lean as CSS only layouts; is there any great differance between these two:

Typical css layout:

<div id="header"></div>

<div id="footer"></div>

Conclusion

If you want to construct your multicolumn layout using only divs, then feel free to do so. Likewise if you want to lay out a form using CSS. But if you would rather use the HTML element designed for being divided into rows and columns, or your boss or customer are breathing down your neck and the CSS just won’t work the way you want it to – remember – there is no law against using a table.

Add to | DiggThis | Yahoo! My Web

Technorati: .

Tony Depledge is a freelance web designer and website publisher. More articles and information on web design, hosting, e-commerce and internet marketing at Depledge Design

Included are six major benefits of creating tableless sites, and how to sell your desire to alter your website to a resistant manager.

Let’s begin with the benefits of a tableless layout. These are only in the order that I feel they should go in, some things are more important to other people, so rank them as you will.

Forces You To Write Well-Formed Code

You cannot have a properly made tableless layout, and use improper and non-standard code. Well, let me correct that – you can (technically you can do it) but it defeats the whole purpose. When you are creating a tableless design, you should be using standards compliant code. I think that anything that makes you get into the habit of always writing clean code is a good thing.

Faster Loading Time

This is absolutely a benfit of a tableless layout, and for several reasons. First, on a fundamental level – tables load slowly. For the most part, unless you set the height and width of your table elements, all the text has to be loaded and rendered BEFORE the table sizes itself to the page. Of course, this is what so many people loved about tables isn’t it? The fact that they were so easily sizeable. The downside is how much more time they take to load.

Okay, so the solution to that loading time is to set all the values explicitly, right? So now we see another downside. Code clutter that increases loading time. First of all, just by themselves, tables take alot of code. How many td open and close tags does your average table based layout have? Tons. Having to set all the values explicitly only adds to the page size and loading time. There are many experiments that have been done on this topic, I’ll point you toward this one that StopDesign did on a remake of the Microsoft website from a tablebased site to a tableless layout. That remake showed a 62% file size reduction of the site, and using their average hits per month for the Microsoft site, calculated that Microsoft would be saving 924 GIGS in bandwidth per day, and 329 Terabytes of bandwidth per year. For any company that pays for bandwidth, these things are important.

Easier to Read Code

If you are using standard code, semantic document conventions, and a tableless layout, your code can be so clean that it looks practically like just regular text with a few extra symbols.

That is a great benefit because it not only makes it easier for you to update, but it makes it easier for a non-technical user to make small alterations to. Additionally, if you work as a web developer in a more freelance capacity, it is common for there to be a full-time web developer who has to maintain that site. Clean and simple to read code makes that a easy transition. We like it when people leave us easy to understand code, right? Let’s return the favor.

Print Alternate Views

When you create a page using a table-layout, you are rather unfortunately locked into a certain layout. Developers who have created table-based websites, as most of us have at some point – particularly if you were in the the industry before the big tableless movement, know that you often have to create a separate printable version of your pages. This can be, needless to say, quite tiresome.

Ease of printing style control is a huge benefit with a tableless layout. You can easily create a single new printing style that applies to all your pages, instead of making them individually. That alone is a huge time saver, but there is more.

While you can control all elements with this approach, the biggest key is organization of information within the page itself. Using the example, let’s assume that the display order we want all our pages to print using the following order: The page header first, the content next, the special news after that, then the link list, and then the footer. However! We still want it to display as it would normally when viewing (meaning the header at the top, the links on the left, content in the middle, news on the right, and footer at the bottom). With a table-based layout, you would have to create a new page to do that special printing organization because the print style will read your columns left to right. With a table-less layout, you are not bound by this. You can order the content in your page however you like, and still control the way it looks… all by using the CSS only!

Additionally, because we can put the content in whatever order we want in the HTML, and then move the content blocks around for website viewing using CSS – we can have ultimate control over presentation.

That is very important because the clean code, and ability to alter presentation, means that your site can be viewable by someone on a small mobile phone screen, a PDA, in all text format can be perfect for someone using a text-to-speech reader, or a braille device, and since the code is clean, it is both backward compatible (with older browsers seeing mostly just the text) and forward compatible with new technologies to come. The flexibilty and organization leads to being able to create a powerful website that takes advantage of some of the possibilities with XHTML, and adding in support in your pages for microformats, or taking advantage of using RSS / ATOM feeds from your site to develop a base of regular readers.

Search Engine Optimization

Due to the fact that you can organize your most important content at the top of your page, without affecting the layout, your page can be better optimized for search engines. For instance, say that I have a navigation bar on the left side of the page that lists tons of parts of the site that are actually great keywords. I could move that navigation bar code higher up in my actual HTML, without changing the layout, because I’m using the CSS to position the navigation where I want it.

Those search engines can also more clearly find common words throughout your document without having to filter through code. Search engines prioritize websites that have a higher content to code ratio, so putting all your style elements into your external CSS stylesheet makes your site highly content based to a search engine. Tableless layouts, as previously mentioned, decrease page size and loading time – another bonus to search engines.

Additionally, being able to take advantage of the RSS/ATOM feeds (see the section directly above) will aid you in some new technology for site indexing as used by all search engines called ROR. (ROR is an XML format summary of your website, like a sitemap, that search engines can access for additional information about your website.)

Presentation Flexibility

Making changes to a CSS based Tableless layout is simple. You can alter the CSS file only, changing as many styles and graphics as you want. The affects cascade through all the pages on your website, and eliminate the need for manually updating many pages.

For one of the best known examples of how powerful presentation can be, you can visit the CSS Zen Garden and navigate through the ‘Select a Design’ links to see the differences. Each of the different designs uses exactly the same HTML file content. The only thing that changes is the CSS file for each one.

Selling Yourself On Standards

Sometimes knowing how to code for standards, and create flexible tableless layouts is not enough. There are some web designers who meet with difficulties from their management. Most often those difficulties are rooted in the management being unaware of the benefits of using tableless content and CSS driven layout.

If you want to design for standards, but you work for a company that is not very forward-thinking in allowing you the time to work on the changes — try this: Make them think about their pocket-book. Point out the cost saving benefits.

For instance, try grabbing a single page of existing code. Clean it up to standards. Compare the page size to before (including image optimization), and count the difference in bytes saved. Multiply that across the number of site pages, and the number of days per month. Then explain to them the amount of bandwidth cost saved monthly if this was done across the whole site. If that isn’t enough, show them how quickly you can make changes to a website once it is CSS driven, and push the idea that you will be able to change the site more rapidly when there are needed updates, and you will have more time to focus on adding in new functionality to the site – instead of spending your time doing maintenance.

Summary

Hopefully, this little article will serve as a way to get you started on understanding why to use a tableless layout, what the benefits are, and you can easily take a look at Layout Gala and download just 1, or all 40 of the tableless layout examples to get you started. However, the best step toward moving to a tableless design is to slowly move your website toward a standard compliant version first, before you get rid of the tables. To get to that point, study as much on CSS as you can, read through the articles here and elsewhere on the web, and moving from table layouts to tableless will be just a matter of time.

End Note: View the original article, including all 9 image examples.

Add to | Digg | Yahoo! My Web

Technorati:

Nicole Hernandez is a web developer with a specialty in web standards and accessibility. She is the owner of Website Style and publishes technical articles on her blog called Beyond Caffeine.