WYSIWYG Report Authoring

Published 05 April 06 12:57 PM

Access 12 has a variety of tools designed to make it both quicker and easier to author applications.  The WYSIWYG report authoring view tools fit both bills.  We saw a bit of them in the posts on Customizing the Issues Template and Starting from Scratch and can finally dive in deeper into the features this time.  A knowledgeable Access developer will not be able to create reports that are significantly different than he could in Access 2003, but he'll be able to build those reports more quickly and without using VBA, ensuring that the reports look the same in a locked down environment as one with VBA turned on.  New Access users will be able to author great looking reports for the first time.

What You See Is What You Get...

The core of the feature is as simple as 'you can look at your data while you're authoring the report'.  This makes it much easier to visualize the report while you're authoring it, and eliminates switching views to gauge things like whether the data all fits or not.  The quickest way to start a new report is to use the Quick Create button, which creates a new simple report with all the fields in the underlying table or query.  In this case, I'll select a query from the nav pane and create a simple report (of course I could start from scratch as well - the only difference is that with Quick Creates I get all the columns and delete the ones I don't want, and starting from blank I add the ones I do want). 

(Click image to enlarge)

Quick Create builds a flat report, with all the fields in the query, presented in the same order as the query:

(Click image to enlarge)

Since the report has all the available columns, the most likely thing I'll need to do first is to remove some.  This is as simple as clicking and deleting (either with the Delete key or from the context menu).

(Click image to enlarge)

The next thing that I need to so is resize the columns to fit my data.  This simple task presented 2 challenges in the old design view. First the other columns had no awareness of the fact that I was changing the width of their neighbor and so didn't get out of the way.  I had to resize my column, then had to move all the other controls out of the way to make space for it.  This wasn't hard, but was annoying and took time to get everything just right.  The second issue was that I couldn't see the data while I was sizing the columns, so it is hard to tell exactly what the report will look like.  In Access 12, I simply resize the thing in layout view and I'm done - I can see the data, and the other columns adjust as necessary.

Reordering columns is similarly easy.  I simply select the column I want to move and drag it back and forth to drop in another location.  Again the other columns resize as necessary.

(Click image to enlarge)

Grouping and Filtering

Grouping is as easy as right clicking and selecting "Group on ...".  For more complex grouping, there is a new modeless grouping dialog that docks at the bottom of the screen and provides all the flexibility you'd expect. 

Adding totals to reports is now very simple, and available on the ribbon.  You simply select the column you'd like to total and click on the Totals button.  For numeric data types, there are a variety of math functions available.  In this case I've selected the text field for Issue, so can insert a count of Issues. 

(Click image to enlarge)

This makes it easy to show how many issues there are for each person in the group.

To filter the data, all I need to do is select the data I'd like to filter for and right-click.  In this case I've clicked on a text column in a row with the value "Active".  Access then proposes a set of text filters for Active.  Had a selected a number, I'd get appropriate filters for that; for a date I'd get date-aware filters (e.g. this week, last month, etc.). 

(Click image to enlarge)

Changing the Presentation

Now that I've got the data I'd like to see, in the right order, I can start adjusting the formatting of the report so that people can understand it more easily.  First, I'll add gridlines to separate the data rows by clicking on the "Gridlines" control on the ribbon:

(Click image to enlarge)

By selecting "Bottom", I get lines underneath each of the rows:

(Click image to enlarge)

My report is quite wide still, and will not print on regular paper in portrait orientation (this is easy to see from the dotted lines in the image below).  It is simple for me to switch to landscape orientation from the ribbon as well, by going to the Page Setup contextual tab

(Click image to enlarge)

Now the dotted lines showing the page borders contain all the text, and I can easily see that my report will print one page wide. 

(Click image to enlarge)

When I flipped to landscape mode, Access just changed the paper orientation and didn't move any controls, so as you can see in the image above, the date and time stamps are no longer right-aligned in the header, and I need to move them.  I can do this in layout view as well, and simply click and drag them just as I would in the design view.

The ribbon provides controls for setting Control Margins (the internal spacing around the text inside the control):

And Control Padding (the spacing around the control itself).  For this report, I've left the margins at the default "narrow" setting, but have increased padding to make the report a little easier to read:

(Click image to enlarge)

To make it even easier to parse the report, we can use alternating row colors to create a "green-bar" style report (I think I just dated myself). 

The alternating row color tools are on the Formatting ribbon, and use the new color controls discussed in the last post.

(Click image to enlarge)

Finally, it is easy to add conditional formatting to a report, to ensure that the reader's eye is drawn to the right records.  The user selects the Conditional formatting button on the ribbon, and sets up the formatting in a dialog. 

(Click image to enlarge)

In the dialog, the user defines the condition, and selects what formatting to apply.  In this case we'll mark old dates in red.

(Click image to enlarge)

The end result:

Starting From Blank

In the example above, we started from a "Quick Created" report, but we could have just as easily started from scratch.  If we'd started from a blank report, we'd use the "Add Existing Fields" taskpane to drag the fields we want to add onto the report rather than deleting the ones we don't want.  All the other functionality works just the same.  Of course I can use "Add Existing" from a Quick Created report as well, either to build a join (this is shown in the Start from Scratch post, and we'll cover in more depth later) or to simply add back a field I've deleted.  In this case, we'll add back the Comments field:

 

(Click image to enlarge)

I open the taskpane from the ribbon and then drag the field I want to the report - its new location is shown by the I-beam cursor.

(Click image to enlarge)

And the column is inserted (and of course the others are moved over to make space). 

Design View

The existing Access design view is still present, and is still super useful for many tasks.  We think the new layout view is faster for most common tasks (and much easier for new users), but we fully expect experienced Access users to switch back and forth between Layout and Design views frequently when authoring reports, and have worked hard to make that switch quick and seamless.  Here's the report we've been building in the traditional Design View.

(Click image to enlarge)

Next Week

I'll be out next week at the Access Advisor conference.  We'll have 5 folks from the Access team there showing Access 12 and teaching tips & tricks in depth.  If you're attending, I look forward to meeting you there!  My plan is to create a post next week about the new Layout View authoring tools for forms, and will hopefully be able to do that from Vegas. 

Comments

# Abigail said on April 5, 2006 4:27 PM:
WYSIWYG is awesome! (Okay, perhaps I'm biased because I worked on the feature.) But it's great to see the hard work of many people come together in a cool scenario.
# AL said on April 5, 2006 7:48 PM:
Your new report views look like they will be very useful.  Your hard work really show off here.  I can hardly wait until you add all that new Excel cond. formatting and Pivot table stuff in Access 13 (hint, hint).

When you are ready to release the "compiled" MDE/ADE versions, I sure hope you are going to let end users fiddle a bit with the report design, filters etc.  Could you say a few words about what will be available in MDE/ADEs for end-users?
# clintc said on April 5, 2006 8:06 PM:
The new adhoc filtering stuff is fully functional but we won't allow report design. Oh, wait--we haven't talked about the filtering stuff yet... Somebody really smart designed that feature :-). Erik is getting to that post.
# Toby Getsch said on April 5, 2006 10:59 PM:
Hey Access Team~

Just checkin' in here.  Been reading some, but you guys are putting up so much good stuff it takes more time to keep up now!  Yay!  ;)  Nice work on more frequent posts and more exciting feature discussion.

I love the way you're putting the power back in the WYSIWYG users hands.  Not everyone digs code and digs digging in deaper to figure out how to make stuff look like they want (read: go to properties and then go to...).  Bringing this stuff to the front makes my job easier and helps me help my clients more.

Thanks,
~Toby Getsch

http://www.tweblog.com
# Ryan McMinn said on April 5, 2006 11:51 PM:
Reports have always had just enough learning curve to turn off many end users. It’s awesome to see such a focus in making reports easy for real users especially considering they are one of the areas that offer people the most value. The idea of adjusting reports in layout view is so much more intuitive.

See you in Vegas!

Ryan

# Barry Moraller said on April 6, 2006 10:19 :
This is exciting stuff.  It should help make my job a little easier, but more importantly it should make report writing something that others in the company can start to feel comfortable with.

# Adam said on April 6, 2006 11:09 :
1. It's really nice to see the Reports functionality finally get an overhaul. Was there any discussion about trying to maintain a level of consistency between the "IDE" for reports (and forms I guess) and the IDE of Visual Studio (in terms of control alignment, etc. etc)?

2. Are custom controls (ocx's?) still talked about at all? If not, what has replaced them on forms and reports?

3. OT: Was there any discussion about using VB.Net/C# instead of VBE? Do you see serious developers using Access as a platform for workgroup application development?

4. OT: What do you see as the role of Access in a workgroup environment? I definitely like it as a RAD tool but in terms of the database backend I wonder how you see SQL Server as a datastore vs. Access? Or what about MSDE/SQL Server Express?

5. OT: What is your support in the upsizing wizard going to be in terms of the new attachments field? Will that go into a varbinary(max) or three separate fields or what?

6. To be honest when I saw Access XP/2003 I thought Access was a dead end development track. I really like all the work that's been put in to Access 07.
# Erik Rucker said on April 6, 2006 2:37 PM:
Thanks for the comments!  We're very happy with the way these features are turning out and are excited to get them into your hands.  

There is no code-level connection between the Access IDE and VS, but we do pay attention to what they're doing and bring over features where we can.  There's a bunch of cool stuff in VS that we'd love to match in the future.  On the control front, ocx's still work great and are the way to get custom controls on to forms & reports.

We did do a lot of thinking about moving to managed code for programmability.  Two things prevented it for this version.  First it is super expensive due to the size of the Access OM.  The effort would have pushed off a huge percentage of the other work we've done.  It isn't clear that there's a way to do only part of the OM, since (a) it would be very hard to get all the parts any given dev would need, and (b) it would be pretty much impossible for that dev to know when starting the project whether she'd be successful with the new OM or if she'd hit a wall.  The second issue is that all exisiting Access apps would be incompatible with the new OM, and backward compatibility is extremely important to us.  We've heard loud and clear in earlier versions difficult migration causes untold headaches for our customers and we're working very hard to avoid that.  This is something that we'd love to do and we're still hard at work trying to come up with a successful solution, but for 12 managed code is restricted to particular parts of the product (e.g. the managed taskpane).

In terms of Access in a networked app, we love SQL as a backend.  SQL makes a great data store for Access databases, and we'll work well with either SQL Express or the full product.  We find that for most applications, linked tables work great, and are easy to manage.  And of course ADP's have been refreshed and work great as well.  Attachments don't have a good analogue on SQL , so they are upsized as a comma delimited list of filenames.  This is an area where a dev can certainly add some value to the upsize process.  Attachments do upsize to SharePoint just fine (they're built on the WSS model), so applications that use attachments may be better served by moving to SharePoint.  SharePoint, of course, also makes a great destination for upsized Access apps (more on that to come in a couple of weeks).
# AL said on April 6, 2006 8:58 PM:
I wonder what the Access team thinks about the world of multi-tier apps (both thin and thick clients).  It seems a lot of self-appointed experts are proclaiming all client server type apps to use a poor programming model (2-tier).  If it does not have a distinct data layer (preferably running a a separate server), then you can't be a real programmer, and your app just won't scale or be maintainable.

Since Access is not really suited to multi-tier apps, our apps seem to be of considered design.

Personally, I have never seen any evidence that separate data layers fulfill either claim (scalability, or ease of maintenance.   I wonder what your opinions are about this rather heated topic.  Can Access ADP apps compete in the Enterprise with hundreds of simultaneous users?  Perhaps the Access team could provide us with some real Enterprise performance data with Server impacts, etc?  
# Stevbe said on April 7, 2006 8:14 :
<This wasn't hard, but was annoying and took time to get everything just right. >

You hit the nail on the head ... reports are my least favorite development task in Access but it looks like you are making it quite a bit easier.

Have the built-in report styles been updated?

I typically make 1 form and 1 report to set my style for autoformatting. Have you thought about making this process easier? Maybe a designer that has all the sections and typical/default controls so I can set them withiout having to go through the whole creation process. I also export them (SaveAsText) so I can push/pull my style between different machines (home, work, re-image, etc.)

Thanks,
# KiwiBruce said on April 7, 2006 2:31 PM:
It certainly looks good so far I want to ask 2 questions
1, The same question as AL, will there be any Run-time filtering or grouping features for users as this is the the real missing link in reporting (without a LOT of coding)

2. Are there any changes to Exporting? I take it there will be PDF. One issue I always have is users always want to export the report to Excel but currently, if the report has groups in it it the export to Excel is a mess and takes a whole lot of cleaning up to make it usable.
# Alex Dybenko (MVP) said on April 8, 2006 2:45 :
Hi AL,
Would like to know the comments of Access team on your questions, but also like to give you some comments.

I think you can easy use Access mdb, for example, as a report engine in multi-tier apps, or perhaps even complete presentation layer - forms and reports. I did not really used it in such way (yet), but looks like latest Access versions works fine with disconnected ADO recordsets (I made several tests)
# AL said on April 8, 2006 11:09 PM:
Hi Alex,

I also have looked into disconnected and cached recordsets in ADPs.  

I found that Access ADPs have a rather chatty interface with SQL Server: ADPs requery all combobox recordsets when switching form views, and close and reopen all subforms with their recordsets when forms (containing subforms) are switched to datasheet and then back to form view.  This is very wasteful.  It also calls the very expensive (takes > 1 second) sp_MSHelpcolumns (takes > 1 second) whenever you use FetchDefaults=True.   Unfortunately, all default values are completely broken in Ac2002 unless FetchDefaults is set to True.  This bug is supposedly fixed in Ac2003, but I have not tested it.

Some of these recordset-requery problems can be greatly reduced by creating public "cached" recordset objects, and assigning them to comboboxes and forms in code when needed.  The technique works fine, but it eliminates a lot of the RAD help from the Access forms interface.  It seems like it should be trivial for Access itself to cache combobox and subform recordsets between form views, so I hope the Access team has this fixed by the time of the next release.

I'm not sure, but I don't think using disconnected recordsets for traditional "online" apps will help all that much - mainly because connected Access ADPs maintain 2 or 3 open connections anyway.  It's unclear if there is any advantage to using a disconnected ADP, relying instead on code-generated disconnected ADO recordsets.  Instead, I just reuse the connections and create cached connected recordsets.  I suspect this is as efficient as using disconnected recordsets or pooled connections.  But I would love to see some data from Microsoft comparing a traditional Access ADP app with an equivalent ADP or .NET app using a disconnected approach or a three tier pooled-connection (MTS-based) approach, with a few hundred or a few thousand users.  I am certainly not in a position to conduct such a set of tests!  

The whole push for ADO.NET seems to be based on the need for disconnected recordsets.  But where is any DATA to show that disconnected or 3-tier is better????  Microsoft should provide such data so that we Access developers can make proper decisions about enterprise application design.

I would really appreciate a few comments from the Access team - I have never seen them mention this issue of Access in the enterprise.  Perhaps they will be able to generate some performance data for the next release?  I would love to be able to show my customers data that PROVES that Access can handle 1,000 simultaneous rapid data-entry users, just as well as a new-fangled .NET app with a 3-physical tier or connection pool layer.
# Jake said on April 10, 2006 9:43 :
I have a lot of stuff stored in rich text format.  Will I be able to display and print rtf in forms and reports?  Will rtf grow and shrink like regular text boxes?
# Erik Rucker said on April 13, 2006 3:45 PM:
This is another consolidated answer with the shorter answers at the beginning, and the multi-tier question at the end.  Its great to have all the feedback & questions!

Are the report styles updated? Yes, they're redone in a big way.  I'll make another post as soon as they're all in a build, but they look great and have both a good selection of very subtle styles and some more complex ones as well.

Can users filter or group in the report view?  Filtering is supported through easy to get at UI, but grouping is not.

Does export to Excel work better?  We're continuing to work there.  Yes, it works better and we've done a bunch of work.  There is more to do, and we're still working on it.  

Are there rich-text controls in forms / reports?  Yup.  They'll present the rich text and will grow / shrink just like regular text controls if you set the CanGrow property.

How does Access fit in multi-tier apps?  Access doesn't natively support multi-tier deployments, but as was noted above, it could be called as part of a solution.  There was another question about the value of multi-tiered apps, and whether they're necessary anyway.  Multi-tiered architectures are useful and can provide significant benefits for some apps, but are certainly not required for the vast majority of applications.  Multi-tiered architectures can provide benefits like sharing logic across multiple front-end apps and dynamic load balancing.  Can you build fast flexible Access applications without multi-tiered architectures?  Certainly.  Are there situations where you'd want more flexibility?  Certainly.  Windows SharePoint Services is a great example of a multi-tiered app.  It uses a set of stateless front-end machines to provide load balancing for scale reasons, and supports many thousands of simultanous users.  It is a little hard to give meaningful perf numbers for something like an Access database going against SQL with n users, since the perf is completely dependant on the nature of the database.  
# A discussion of what's new in Access 12 said on April 14, 2006 4:35 PM:
Last week we looked at the WYSIWYG report authoring tools, this week we'll take a look at the similar...
# A discussion of what's new in Access 2007 (formerly "Access 12") said on June 13, 2006 4:36 PM:
The last regular post was on Sorting and Grouping in Reports, and that followed a post about Sort &amp;amp;...
New Comments to this post are disabled
Page view tracker