Performance and scalability are among our strongest focus in WebScheduler v3 release. Since Timeline view is capable to show a wide range of data (from minutes to quarters), loading all the data at once will significantly degrade the server and client performance and ultimately slowing down the application responsiveness in overall. The problem is even more noticeable when the loaded data is relatively huge and when Quarter view mode is used.

WebScheduler 3 addresses the performance bottleneck from top to bottom by introducing smart client paging (EventPageSize),  ViewPort paging, and server paging. The smart client and ViewPort paging are designed to provide paging solution for the client-side which dramatically improves user experiences. I’ve discussed the client paging features in my previous blog post.

In this post, we’ll learn the new server paging capability in WebScheduler 3, and how you can implement it in your application. Let’s take a clear and deep down look at it.

Concept

Designed to be an enterprise-ready scheduling component, we’ve added numerous new features in WebScheduler 3 to control the data retrieval mechanism. One of the most powerful features is server paging.

Server paging is an innovative feature built to eliminate sluggish performance due to the large data download while working in Timeline view mode. With server paging enabled, WebScheduler will download only a small chunk of data based on the viewport during initial load and intelligently requests more data as users scroll downward. This means reduced page load time and increased overall application responsiveness.

Not only that – you can also combine the server paging with smart client paging, JSON serialization and other features to boost your Scheduling application performance even more.

The following screenshot shows the WebScheduler with server-side paging enabled. Notice that it will load data on demand as needed.

Benchmark Result

To compliment this post with a more realistic performance comparison, I decided to do some simple testing and provided the screenshots that show the data and response time benchmark of server-side paging. In this benchmark, I’m using HighPerformanceScheduler sample which is included in the WebScheduler’s sample.

Also keep in mind that the HighPerformanceScheduler sample is using database with 3000+ records of events with 66 resources. All events are purposely recorded within 1 month to load test the WebScheduler performance in Timeline month view.

Using HttpWatch Professional 6.1, we can inspect the data size and the content returned from server. Notice that WebScheduler with server paging enabled loads only 176KB of data. That’s nearly 10x smaller when comparing it with server paging disabled which yielded 1553KB (1.5MB).

In addition, the server paging also significantly reduces data transfer time. For instances, assuming if you have 100kb/s internet connection, the load time with ServerPaging enabled will be done in approximately 1.7 seconds. Contrary, you will need to wait at least 15 seconds or more without ServerPaging.

The beauty of server paging is that it also keeps your browser light and responsive by rendering only a small amount of data at a time. Instead of loading all 3000 events at once, WebScheduler makes efficient use of resources by loading required events on demand when the page is scrolled downward.

You might be wondering how WebScheduler detects which data to be loaded in the next request. That is where smart client paging and ViewPort paging comes to rescue. To learn more on the new performance improvements in WebScheduler 3, please see the video below.

Implementation

And here’s the best part. Taking advantage of this powerful feature isn’t rocket science – thanks to the WebScheduler’s bare-metal architecture. All you need to do is simply enabling the EnableServerPaging property in ViewSettings under the TimelineView property group.

Note: Server paging feature is only applicable when the client paging is set to ViewPort or Both. For certain scenarios with smaller data (less than a thousand of records in a month view), the server paging may not be necessary enabled so that the complete data can be transmitted in a single page load. In such scenarios, the client paging will perform data rendering immediately.

That’s all for now. I’d love to hear any comments, feedback or thoughts about this feature. Feel free to drop your comments here or post it to our forum.

Warm Regards,
Budianto Muliawan

Apparently, Internet Explorer has a serious flaw in performance when a script is trying to add styles programmatically while loading, and at the same time when layouting is performed by other scripts.

To eliminate the performance issue, all styles in WebMenuBar should be defined as CssClass instead of using server-side predefined styles.

For comparison, I have attached two samples (with and without CssClass). Run the samples and compare the performance difference between them.

Note: This technique also works on standalone WebToolBar which causes the same issue.

Regards,
Handy.
Support Engineer.

One of the feature request we often received in the past is the ability to specify the visible hours in Day, Week, and Split views. By default, the hours in these views start from 00:00 to 23:59. You can now customize the visible hours to start and end at specific hours.

To customize the visible hours, simply specify the visible start hour using ViewSettings >> VisibleStartTime property and visible end hour using ViewSettings >> VisibleEndTime property. These configurations are applied globally, means Day, Week, and Split view will use the same visible hours.

The following screenshot shows scheduler that starts from 9 AM and ends at 7 PM. Note that work week styles are still applied at the specified hours.

<ViewSettings SelectedViewMode="Week" SelectedDate="03/11/2008 10:00:00" 
   VisibleStartTime="t0900"VisibleEndTime="t1900">
</ViewSettings>

Event rendering will be adjusted according to these settings. For example: the visible start time is set to 09:00 AM and visible end time is set to 07:00 PM. All events that fall within the date range will be rendered. Any events that start at 08:00 AM and ends at 10:00 AM will be rendered from 09:00 AM to 10:00 AM following the visible start time. The original duration of that event will not be altered; it can still be seen from the detail callout.

The total of events that occur in a date is displayed as the tooltip of the date in the calendar area. When there is only one event that occurs in the specified date, the title of the event is displayed as the tooltip. When custom visible hours are specified, some events might not be included in the hour area. Although some events are hidden, users can still see the total of all events that occurs in the date in the tooltip of the date in the calendar area.

If you have any feedback regarding this feature or you think this feature could be further enhanced, feel free to drop your comments or post your opinion in our forum. We’d be glad to hear them. Happy scheduling, everyone!

As we’ve just released WebUI Studio 2009 R2 service pack, you can now download and try many exciting new features that we included in the release. Read more about the new release here.

One of the much anticipated new features is the virtual group paging capability that we shipped in the service pack, which I’ve discussed in my previous blog post. In this post, I’ll show you the step-by-step walkthrough to use the virtual group paging along with client binding in your application.

The following walkthrough presumes you have been familiar with the client binding and batch update feature that introduced in the initial WebGrid 7 release. To save time and space, this walkthrough will be focused only on the new group paging features. If you would like to see the walkthrough for client binding and batch update, please refer to WebGrid 7 online documentation.

Configuring WebGrid for Virtual Load and Group Row Paging

In this walkthrough, I’m going to use the ClientBinding_SmartBatchUpdate.aspx sample that shipped in the initial WebGrid 7 release. To work with the sample, launch the C# Samples which is accessible from WebGrid 7 program group in the start menu.

Once you got the sample ready in your Visual Studio IDE, click on the WebGrid instance and open Property Window.

The sample used classic paging mode, so our first step is to change the paging mode to VirtualLoad since the group row paging is an integral part of VirtualLoad paging. To set the paging mode, expand LayoutSettings and set the PagingMode property to VirtualLoad. See below.

The next step is to enable the group row paging, customize the group row paging size, and optionally enable the preload group totals as well as other client binding related settings.

Still in the Visual Studio’s Property Window, expand the ClientBindingSettings property. You’ll find most of the client-binding related settings centralized in this property group. Enable the group row paging by simply setting its property to true and configure other settings to follow the screenshot below.

We’re done with the WebGrid-level configuration.

Configuring WebGrid LINQ Provider

After configuring the WebGrid to use proper client binding settings and group row paging, the next step is to configure the new LINQ provider in your application.

To use WebGrid LINQ provider in your application, add the ISNet.Data.Linq assembly from WebGrid installation folder to your application’s Bin folder. If you’re installing using default setting, the new assembly should be located in C:Program FilesIntersoft SolutionsWebUI Studio for ASP.NETWebGrid.NET 7.0Bin.

Note that this is a new assembly shipped in the service pack installer. Download the latest service pack installer here, or obtain the assembly in the provided samples in the last section.

Handling Data Operations with LINQ-to-SQL Classes

Since we’re using client binding mode with WebService datasource, we need to specify the ServiceUrl property to the path of the web service that handles data operations requested by WebGrid. The sample used in the walkthrough is using WebService.asmx.

In this walkthrough, we’re going to define the service methods used to perform data selection and batch update. The select method is defined in SelectMethod, while the batch update method is defined in BatchUpdateMethod. The property settings can be seen in the screenshot below.

After wiring the service methods, the final step is to write each web method in the web service that corresponds to the specified service methods above.

Open the code-behind file of the web service to your Visual Studio IDE by right clicking on App_CodeWebService.asmx.cs then choose View Code.

Write the code for the data selection such as below.

[WebMethod]
public object GetPagedBugs(DataSourceSelectArguments selectArguments)
{
    BugTrackerModelDataContext context = new BugTrackerModelDataContext();
    context.DeferredLoadingEnabled = false;

    WebGridDataProvider provider = new WebGridDataProvider(context.Bugs.AsQueryable());
    object data = provider.Select(selectArguments);

    if (data != null)
         return data;

    throw new InvalidOperationException("Unsupported operation type!");
}

So simple, isn’t it?

As I’ve mentioned in my previous post, the Select method of the WebGrid’s LINQ provider automatically handles all data operations – from data paging, grouping, filtering, aggregate computation, group header selection, and group row paging.

I’ve also mentioned that the LINQ provider supports data transaction operations too – such as Insert, Update, Delete and BatchUpdate. The following code shows how to perform batch update using the new data provider.

[WebMethod]
[GenerateScriptType(typeof(Bug))]
public TransactionResult UpdateBugs(List changes)
{
    BugTrackerModelDataContext context = new BugTrackerModelDataContext();
    WebGridDataProvider provider = new WebGridDataProvider(context.Bugs.AsQueryable());

    return provider.BatchUpdate(changes);
}

It’s as simple as that – thanks to the bare-metal architecture built on the client binding, batch update, virtual load paging and the LINQ data provider to produce this level of component integration.

Now save your changes and view your page in the browser. Try to group the column by Operating System and you should see something like the following.

So far, you have learnt how to enable group row paging, customize the page size, activate group total preloading, and use the new LINQ data provider to simplify client-binding data operations. Your next step is to test the new features and implement them in your web apps.

Download Samples

In case you haven’t got the chance to download the full service pack installer, you can quickly download and install the latest bits right from your Update Manager. However, it’s highly recommended that you to go through downloading the full installer to enjoy numerous new and enhanced samples that we included in the release.

You can find the new samples that I used in the walkthrough here. To try it, simply copy the entire folder into the root project of WebGrid C# Samples. I’ve excluded the references to WebGrid and other framework assemblies to reduce the download size, although I decided to include the ISNet.Data.Linq assembly for your convenience.

Enjoy and happy developing!

All the best,

Jimmy.

We’ve been heavily focusing on performance and scalability aspects in the last two versions of WebGrid. As you may have already aware, WebGrid Enterprise 7 introduces numerous noteworthy new features such as client binding, JSON serialization, virtual rendering, efficient batch update and more – which elegantly address performance issues commonly found in enterprise applications.

The next release of WebGrid will still be strongly focused in various areas of performance to deliver even better data visualization component that is not only rich, but also speedy and highly scalable. Many of the new enhancements in the next release are designed to support combination of multiple advanced features, such as using client binding together with virtual load paging, grouping and data aggregates.

This post details some of the key enhancements to give you an insight for the usage in your applications.

Preload Group Totals

WebGrid 7 introduces a new client binding model where the data rendering is performed in the client-side instead of server-side. While there are many benefits with client binding, it falls short when it comes to extensive data aggregation such as calculating group totals on several hundreds or thousands of records.

The upcoming release will include a new capability to preload the group totals during server-side data fetching process, and hence eliminating the needs to compute heavy aggregation in the client-side, while maintaining the data footprint in a good balance.

This new feature also works along side with virtual load paging, which makes more sense on the “preloading” factor. Your users would definitely like the ability to see all group totals without have to expand each group to retrieve the rows. See the following screenshot for details.

When using ServerDataSource type, the group totals will be automatically computed without additional user codes. Simply enable the PreloadGroupTotals property in ClientBindingSettings should do the job.

This new feature is also consistently supported by other client binding data source such as Web Service and WCF Service. Read the explanation in the latter section.

Group Row Paging

One of the advanced features that truly sets WebGrid apart from other Grids is its VirtualLoad™ paging capability. When enabled, virtual load retrieves only the first subset of data and then smartly loads the rest records as users scroll downward. The virtual load also uniquely supports grouping condition by displaying only the group headers and group totals in the first load. When users expanded a group row, WebGrid loads the child rows on demand via AJAX callback and then seamlessly inject it into the group row element. This gives users the feel of working with desktop apps.

Everything is good until your users accidentally grouped a data resulting with large amount of rows per group. It becomes worse when the Grid is working in client-binding since the rendering operation is done in the client-side. Imagine looping through thousands of records to perform string-extensive operations, the browser itself naturally refuse to complete the operation. And hence, you’ll get a prompt that ask you whether you want to stop or continue the script. Although you can choose to continue the script, it will still take several seconds to complete. This is certainly not a desirable result for most of today’s users who expecting applications with rich experiences.

Toward that end, we’re researching a solution that will not only address the performance issue permanently, but also works consistently across existing features and certainly with an intuitive user experience. As the result, group row paging is born.

With the new group row paging capability, you no longer have to worry how much data your Grid is presenting, whether they are grouped or not, whether they are filtered or not, WebGrid will display your data in the same timely fashion – consistently. To understand how group row paging works, please see the following image which also shows the new group row paging user interface.

The above sample is using GroupRowPageSize=10 configuration, which means only 10 records should be fetched in a time. As shown above, the new group row status enables users to easily understand the current state of the group row. It’s especially useful when the GroupRowPageSize is set to a larger value such as 100 (50 is the default) as users can see the current status without have to scroll back and forth to the group header. The new status bar also serves as command bar and allows room for improvements in the future, such as adding more buttons related to the group’s context.

Compared to the original sample without group row paging, the same group with 1,000+ rows now loads in a fraction of second, and that’s about 100x faster. The group row paging will consistently support multiple groups and other grouping-related features too.

It’s also noteworthy to mention that other useful features such as data editing, batch update, and row selection persistence will continue to work flawlessly along with group row paging.

Virtual Load Support For Web & WCF Service

Still around client binding and virtual load, we’ve now added virtual grouping (means virtual load + grouping) support for WebService and WCF Service as well. In the current release, the grouping process will invoke a Select command against the underlying WebService and retrieve all groups and rows from the database, which ultimately transmit 1-2MB size of data to the client. In most cases, you’ll get a server-side exception when the data exceeded 2MB because .NET’s JSON Serialization limits it to only 2MB by default.

In the next release, WebGrid will automatically send a new SelectGroup option in the select arguments when it attempts to perform grouping, or perform data selection in grouping conditions. This will allow developers to handle the group retrievals based on the select operation mode in the server-side and returns only the groups information to the client.

Our experiment shows that virtual grouping using Web Service or WCF Service is at least 4x faster and much more efficient than using ServerDataSource, especially when the processed data is huge. That is possible because developers have granular control over the data selection process, and in this case selecting only the groups from the backend directly without have to deal with the data rows.

The following code snippet demonstrates how it works.

if (selectArg.OperationType == SelectOperation.SelectGroup)
{
     var groupResults = dataSource.GroupByMany(selectArg.GroupByExpression);     
     return ProcessGroupRows(groupResults, selectArg);
}

Notice that the select operation type and group expression will be provided in the select arguments to allow developers to handle their data selection. The above sample is using LINQ to SQL to process the grouping request, which returns only the group rows required by WebGrid.

The two-minutes video below shows the improved performance and the user experiences when virtual load, group row paging, client binding and batch update are enabled together.

Furthermore, the new PreloadGroupTotals and GroupRowPaging feature that we discussed earlier can also be used with WebService/WCF Service data source type. In the client-side, WebGrid will perform the data rendering in consistent fashion, such as the new group status interface and the group loading behaviors.

WebGrid LINQ Data Provider

In addition to the performance and UX improvements, we’ll also ship LINQ to SQL data provider for WebGrid in the next service pack release. The new data provider greatly simplifies the codes to perform data operations using LINQ to SQL, specifically when paired together with WebGrid’s client binding.

The WebGrid LINQ data provider minimizes complexity and slashes dozen line of codes into one line. See the following comparison.

The following is the original codes that we shipped in our WebGrid 7 samples.

And here’s the new approach using WebGrid LINQ Data Provider.

One code rules it all – that’s what I really like about this new data provider. The generic-based class architecture enables you to easily instantiate the provider on any of your data model by simply passing the data type – making development more efficient and fun!

In this first version, the WebGrid LINQ provider will automatically handle the following select operations during client binding:

• Data Selection
• Sorting
• Filtering
• Grouping
• Paging and Total Rows Count
• Group Selection
• Group Row Paging
• And yes, group totals too.

In addition to data selection, the provider also includes full-featured transaction operations, such as:

• Insert
• Update
• Delete
• Batch Update

And now comes the best part, the LINQ data provider is free for all WebGrid licensees. To start using it in your application, simply add reference to the new assembly named “ISNet.Data.Linq” which can be found in WebGrid’s installation folder. When the enhancements are rolled out in the next service pack, I’ll post more blogs to cover how to use them in more details.

Summary

This blog post gives you an insight and early look on some key enhancements that we’re currently working on for the next WebGrid release. Customers who wish to test drive these new enhancements, please obtain the nightly build (and yes, we have prepared some new samples too!) by directing your email to our Support Team.

We hope customers to participate in the beta testing and give feedback, so we can review and take account your feedback before wrapping up the final features. You can send your feedback to Feedback Team for private discussion (if your feedback includes confidential information related to your apps etc), or to Community Forum for open, shared discussion.

All the best,
Jimmy.

In previous version of WebScheduler, detail box will be displayed when you click More in Month view. In the latest version, detail box is also used in other views (Day, Week, and Split views) when client paging is enabled. In Day, Week, and Split views, detail box will be displayed when users click paging arrow indicator in hour area.

Detail box will adjust its height based on the number of events that occurs in the event block. If there is a lot of event, it is easier and more convenient to enable paging in the detail box.

To enable paging in detail box, simply set LayoutSettings >> EnableDetailBoxPaging property to True. The page size can be specified in LayoutSettings >> DetailBoxPageSize property, which by default is set to 5. This means the detail box will hold maximum 5 events on every page. Note that when detail box paging is enabled, all views that uses detail box will use the configuration.

As explained in previous posts, WebScheduler 3 focused on performance and usability improvements. To improve the performance when rendering events, especially when large dataset is used, Client Paging feature is introduced in WebScheduler.

In Day and Week view, events that occur on the same period are rendered as overlapping events. However, when too many events occurred on the same period, it is difficult for user to see and differentiate these events, as seen in the below screenshot.

Client paging can be enabled in Day and Week view using ViewSettings >> DayView | Week View >> EnableClientPaging property. Client paging is view dependent, which means it can be enabled in one view and disabled in other views.

Both Day and Week views have the same layout structure, which divided to all-day area and hour area. Client paging applied to each area are implemented differently, following the nature layout of the area.

Client Paging in Hour Area

Before we continue, let’s synchronize the term. Events that occur in the same period is called overlapping events and all of the events are considered as one event block. In the below screenshot, event blocks are marked by yellow and purple square. Each event block is divided to several columns, will further called overlapping blocks (marked by pink square), depends on the start time and duration of overlapping events in the event block.

In hour area, the maximum number of overlapping events displayed in an event block is determined by ViewSettings >> DayView | WeekView >> EventBlockSize property. In the above screenshots, 8 overlapping events occurs in the same period (marked by yellow square). If client paging is enabled and EventBlockSize property is set to 2, events rendered in the first two overlapping block will be displayed and the other events will be hidden. A small paging arrow indicator will be displayed at the upper right corner of the block. When the indicator is clicked, detail box that lists all overlapping events included in the event block, will be displayed.

Client Paging in All-day Area

The following screenshot shows overlapping events in all-day area. The start time and duration of each event determines the overall event layout in this area. In the screenshots, eight rows are needed to render all the events.

When client paging is enabled, you can determine the maximum number of rows in all-day area using ViewSettings >> DayView | WeekView >> AllDayEventPageSize. If the property is set to 5, events rendered in the first five rows will be rendered and the other events are hidden. A paging arrow indicator is also displayed at the bottom of the area to indicate there are more events that occur in the specified time. When it is clicked, all the hidden events will be displayed.

Feel free to try client paging samples in our live demo and post your questions and feedback in our forum.

In the following section, we’ll learn how client paging work specifically in Timeline View (the other views will be discussed in future blog posts). We introduce several client paging modes which can help improving overall application response based on your scenarios.

Let’s start by enabling the client paging in Timeline view. We’ve made it extremely easy to use, so that you can enable the feature by simply setting EnableClientPaging property to true. The property can be found in ViewSettings, then expand TimelineView property.

After enabling the client paging, the next step is to choose the client paging mode that is more suitable to your application scenario. WebScheduler 3 introduces three client paging mode to choose from:

1. Paging based on number of events
   Called EventPageSize mode, this paging mode restricts the numbers of event displayed in each Timeline cell. If the total number of events exceeds the value of the EventPageSize property, an arrow indicator will appear notifying that more events are available. Click on the arrow indicator to reveal the complete events in the Timeline cell.To use this paging mode, simply set the ClientPagingMode property to EventPageSize.

   
   

2. Paging based on screen viewport
   Called ViewPort, this paging mode will render all events based on the currently visible viewport. This means that even if you have hundreds of resources, WebScheduler will present your events in consistently fast performance. When scrolled down, WebScheduler seamlessly render the complete events of the new visible viewport. As the result, this advanced paging mode significantly improves overall responsiveness and user experiences.
   You should consider using this paging mode if you have fairly large number of resources bound to your WebScheduler.

   To activate this mode, set the ClientPagingMode property to ViewPort.

   

   

3. The combination of both event size and viewport paging
   This mode combines the best of both EventPageSize and ViewPort client paging for the most efficient event rendering. With this mode, the events will be rendered based on the visible viewport and also be restricted based on the number of allowed events. This mode is best used for applications with considerably large number of resources and events bound to WebScheduler.

   To enable this mode, set ClientPagingMode property to Both.

   

At this point, you should have learnt the new key features in WebScheduler 3 that elegantly address critical performance limitations in web-based scheduling application. So if you’ve got large, enterprise data to be presented in scheduling interface, go ahead, download and try WebScheduler 3, and impress your users big time!

Last but not least, you can find out more information on WebScheduler 3’s new features here and the live demos here. For questions and feedback, please drop by our forum.

Happy scheduling!

Warm Regards,
Budianto Muliawan.

To get started, right click on a WebScheduler instance and select “WebScheduler Database Wizard” option to use this embedded tool.

Follow the onscreen instruction below to quickly create your new WebScheduler SQL database.

Database name drop down list
When the connection to the designated SQL Server has been successfully established, simply specify a new database by typing the name on the textbox. Alternatively, you can select one of the existing databases from the drop down list. Press “Create” and all required tables for WebScheduler with standard fields will be created automatically.

“Get SQL Script” button.
The database wizard also provides a more advanced option to generate the SQL script for the tables definition. The SQL script is primarily useful if you would like to customize the fields definition or add more fields to the table. Simply click on the Get SQL Script button to obtain the complete SQL statements and easily apply it in your own database, for example a Microsoft Access database.

The following screenshot shows the result of T-SQL compatible script.

Note that there are 2 options for the script definition; “MS SQL Compatible” and “MS Access Compatible”. You can choose the one that suit your preferred database provider.

That’s all for now. if you have any questions or feedback. Please share with us in our forum.

Warm Regards,
Budianto Muliawan.

If you’re building a large scale, enterprise resources planning application that involve thousands of resources and events in a single month view alone, you would have quickly realizing serious performance issues during the development process. In this post, I’ll share some insights on the common pitfalls and bottleneck in performance, and how our latest scheduling component completely address them in elegant ways.

The Challenges

There are at least 4 factors that would lead to performance issue in most enterprise applications and specifically in scheduling applications.

1. Huge data transfer size.Take a look at our recent case study on a car rental application. The car rental could have over 3,000 events made in a month. In most scheduling component in the market, all data will be retrieved at once in the page load. That transmits over 2MB of data sent over the cloud which translates to 6-7 seconds waiting even on a broadband connection.
2. Long rendering process.With rich user interface possible nowadays, web developers often forgot that a web application is not a desktop application. The nature of web application still have several common constraints such as the amount of elements which are considerably good on a page. In the case of enterprise application, serious performance bottleneck could arise due to the massive objects creation and long rendering process which could take 8-10 seconds for a page bound to several thousands of data.
3. Heavy backend query.
   
   Most datasource controls introduced in ASP.NET don’t enable paging by default. While it may not be a significant issue in relatively smaller application, it could be a great showstopper for enterprise application with millions to billions worth of data. Non-optimized database query itself could cause performance issues in at least three ways: the heavier workload and resources required to compute the query, huge data transmission from the backend to business layer and ultimately yielding more extensive operation in the UI layer.
4. Poor data processing.Specifically for a scheduling component, poor data processing logic is often a factor that causes performance issue. Scheduler is a unique component that process data in several phases, such as resources categorizing, data grouping and more. Thus, improper data processing logic could result in longer time required to compute the final shape of the data required by the scheduler interface.

The Solution

WebScheduler 3 is strongly focused on addressing performance issues and improving application scalability at the same time. One of the our key goals is to achieve a consistent performance while loading a scheduler bound to thousands of data – for example, 1-2 seconds regardless of the data size.

ViewPort paging was born as the result of our extensive R&D. It is specifically designed for Timeline View (Gantt Chart Style) which makes more sense due to its layout nature that display huge data in a single resource. To completely eliminate the key performance issues discussed above, we also invented three more innovative features that work in conjunction with ViewPort paging. They are event-based client paging, server paging and efficient data categorizing process.

Instead of loading huge data on every data request, ViewPort paging works by loading only a small chunk of data in the first load which seamlessly fills the data based on the available real screen estate. It will load the rest of data on demand as users scroll downward. Also keep in mind that ViewPort intelligently saves a cache of loaded data, so it won’t retrieve the same data twice. The result is maximum performance, increased responsiveness and extremely smooth user experiences.

The ViewPort implementation doesn’t merely handle data paging process, it  also takes account every single feature that associated to it, say, new event creation, recurrence editing, and data drilling. It also flawlessly handles a vast array of complex scenarios such as drag-drop operation across resources and time, multiple selections, views switching, and more.

In addition to ViewPort paging, WebScheduler 3 also implements smart client paging to other views including day view, week view,  split view and all day area view. We also add client paging interface to the details box in month view.

All in all, WebScheduler 3 successfully delivers on its key objectives to redefine a new standard in performance for enterprise-class usage and improving user experiences at the same time. The following chart shows the performance benchmark tested in various browsers.

Our engineers will soon post more coverage on other new exciting features such as customizable time intervals, visible hours, disabled time and more. So stay tuned!

As the word said, pictures worth a million words. Videos worth a zillion. Watch the video below and see the new performance improvements in WebScheduler 3.

You can also experience it yourself by trying our new Blitz rent-a-car reference sample available online.

Learn More

WebScheduler 3 is released – download your 30-day trial copy today to experience the exciting new features for yourself.

More resources on WebScheduler 3 can be found in the following links:

Overview

Performance Benchmark and Comparison

Powerful Client Paging Capability

Top New Features

Top 10 New Features Video

Live Demos

All the best,
Jimmy.