Creating Screens with the LightSwitch HTML Client (Joe Binder)

Beth and I touched on a few of the new features of the upcoming HTML client for LightSwitch in our Channel 9 video chat last week, but I thought it’d be worthwhile to cover each topic in more detail. Today I’ll walk through the application user model and screen development, then follow-up with in-depth posts that cover writing code, theming, and the application architecture.

The HTML Client Preview will be available for you to try out yourself soon. Keep an eye on this blog and the LightSwitch Developer Center for availability.

Getting started

Let’s get started by creating a new LightSwitch project. The first thing you’ll notice is that there are a few new project templates available in the LightSwitch 2012 HTML client preview.

The templates suffixed with (JS/VB) and (JS/C#) create a project with an HTML client and Visual Basic or C# middle-tier, respectively. The “LightSwitch Application (Visual Basic)” and “LightSwitch Application(C#)” templates create a project with a Silverlight client and middle-tier in the given language, just as they did in Visual Studio LightSwitch 2011. If you start with a Silverlight-based project, you can always add an HTML client later, and vice versa. Let’s create a new Silverlight-based project for this example.

The Solution Explorer has been restructured to more clearly delineate the server and client(s). Data sources, entities, and queries appear under the server node and screens appear under the client node(s).

The client with “(Startup)” listed in its name will be run when you press F5 to debug the application.

We’ll use the entity designer to quickly add some data entities to describe contact information. The entity designer in the HTML client preview is identical to the entity designer in Visual Studio 2012 RC.

With the entities and some basic Silverlight-based screens created, we can now add our HTML client by right-clicking the top-level “Contact Application” node in the Solution Explorer.

If we started with an HTML Client, we’d also see an option for adding a Silverlight client: the HTML client preview allows you to have zero or one Silverlight clients and zero or more HTML clients. The task-focused nature of mobile web clients means that it’s common to have multiple clients talking to the same middle-tier, each with their own specific workflow or user experience.

Once the new client is added, it is automatically marked as the startup client for the project.

If you need to change the startup client, just right-click the client you want to debug and select “Set as startup client”.

Adding Screens

Screens/Pages for the HTML Client are added through the same “New Screen …” dialog that’s used for Silverlight clients. We have a pretty simplistic list of mobile-specific templates in the dialog, but we’d love to hear your feedback as we finalize the list. Screen templates are extensible, so we’re also excited to see some additions to this list from our partners in the near future.

The Browse Data Screen creates a full-screen list. This template is commonly used in conjunction with the View Details Screen, which shows a read-only view of a single record. We created separate templates for viewing and creating/editing detail records because mobile user interfaces are typically optimized for reading, and showing touch-oriented edit controls can impair the readability of the screen. Nonetheless, you can use the same details screen for reading and editing if you like; we just provide both options.

Once created, you’ll notice that we’re using the same screen designer that’s used for Silverlight—the data/view model is listed on the left and the screen layout/content is on the right.

Let’s add another detail screen that we can hook up to the list, such that the details screen is shown when the user taps on a list item.

Note that when we include child collections on the details screen (e.g., “Contact Photos” and “Friends”) the template places each list in a separate tab. This division is done by default for two reasons:

1. The mobile device is unlikely to have enough screen real estate to show multiple lists on the same screen.

2. In general, having a single scrollable region in a mobile web application is easier to use because mobile browsers don’t show a scrollbar. Having multiple scrollable regions on the screen can make the swipe/scroll gesture ambiguous when the scrollbars aren’t visible.

With two screens in the client, we need to tell LightSwitch which screen should be used as the “Home” screen for the application. The home screen will be shown when the application is started, and the home button shown on other screens will link back to the home screen. We have some logic to guess what to use for the home screen, but you’re best bet is to set the home screen explicitly in Solution Explorer.

Configuring application navigation

While JavaScript is a powerful and flexible language, we didn’t want to force developers to write JavaScript for tasks that could more easily be accomplished with the designer. Defining the application navigation and workflow is a great example of plumbing that you often have to express in code; but we chose to make this a code-free experience in the HTML Client, allowing you to link screens together with a few mouse clicks. Of course, you can still create a button and call the code if you need to do something more advanced—conditionally launch different screens, for example—but the UI-based experience covers most scenarios. Here’s how it works.

When you select a control in the screen designer, a list of “actions” will be displayed in the property sheet. These actions represent user gestures that can be performed on the control. Currently, “Tap” is the most common action, but controls may support things like “Swipe”, “Hold”, and so on in the future.

You can configure actions to execute methods that you’ve written or built-in methods associated with the view model. Click the link next to the action to configure it.

The “Write my own method” option is not yet supported, so let’s explore the methods that LightSwitch provides.

Notice that there are pre-defined methods for changing the selected tab/section on the screen, showing a dialog, navigating to the home screen, and launching any other screen defined in the application. Additionally, methods associated with anything on the screen view model will be shown here.

Since we want to show the contact detail screen, we’ll choose “ShowViewContactDetail”.

There are a few new options for showing a screen with the HTML client. The Save (default) option is analogous to the Silverlight client’s Application.ShowScreen() method, meaning that the screen will be launched with a new data context. The OK/Cancel option provides a modal experience, whereby users can make multiple edits to a record and choose to accept or cancel them as one edit; the changes are then added to the parent screen’s change set. The Back option is useful when you have a record with a lot of fields, and you want to divide the task of viewing or editing groups of fields into separate UI. There is descriptive text in the dialog to help describe the exact behavior you’ve chosen.

In this example, we want to use the Save option. Since we selected a details screen that accepts a Contact as a parameter, we also need to specify the parameter value, which is expressed as a binding to the Home screen’s view model—the selected item in the contact list.

The application navigation model

When the application is run, our list screen is shown and the details screen will be launched when a list item is tapped. The list does not include gestures for sorting and searching yet; you can use the query designer to configure the sort order in the meantime.

One important difference between the HTML and Silverlight client is readily apparent when we tap on an item: only one screen is visible at a given time. A built-in back gesture allows you to move back in your task flow. As mentioned earlier, the screen is divided into top-level tabs (Details, Photos, Friends) by default.

We can now customize this screen to include an “Edit” button. We’ll use the Add/Edit template to create the screen.

Now we can just add a button to the existing ViewContactDetail screen that will show the ContactDetail screen.

In this example we’re using the OK/Cancel mode, which will cause the edit screen to be shown as a sub-screen of the contact detail screen.

Note that screens do not have Save gestures when they’re hosted as sub-screens.

Once we’ve made changes, we can click OK—the check icon—and see that the changes we’ve made have been added to the parent screen’s changeset.

Clicking Save will now save the changes we made in the sub-screen.

Dealing with multiple screen sizes

One of the most challenging aspects of building mobile web applications is optimizing for the screen size: the user may have anywhere from 480 to 1200+ pixels available for the width. We’ve just begun work to improve our layouts to be more adaptable to varying screen sizes, but there are a few hidden tricks you can use to work well in wide and narrow environments.

For example, our edit screen looks very silly in wide mode. (See above). What I’d really like to do is use some of that horizontal space if it’s available, but stretching the controls is a waste of space and distracting. Instead, we can use a columns layout and set a minimum width on each column.

(Note: be sure to uncheck “Stretch to container” for the width and height of each column also.)

Now when we run our application, the screen will use a two-column layout when we have at least 700 pixels—for example, on a tablet.

But if we are using a narrow device the columns will stack vertically and scroll if needed.

This area is ripe for some simplification, but I thought I’d pass along the tidbit in case you’re interested in seeing the app in a variety of screen sizes.

Next Up

This is an extremely simple application, but I hope it gives you a feel for the basic user and development models for the LightSwitch HTML Client. We’re putting together a detailed walkthrough of everything we’ve covered today that we’ll publish when the LightSwitch for Visual Studio 2012 HTML client preview becomes available. Keep an eye on this blog and the LightSwitch Developer Center for availability.

I intentionally left out any coding experiences in today’s post to illustrate the types of tasks you’ll be able to do without writing HTML, JavaScript or CSS. But we know a lot of you want to see some code examples and understand our application architecture—both are on tap for upcoming posts along with a theming overview.

As always, we’d love to hear from you over on the forums. Thanks for all of your feedback, suggestions, and encouragement!

Nice work Joe !! Regarding screen widths we've got windows phone which is currently 480 x 800, and we're soon to have Windows RT and Windows 8 with the docking panes set at 320 px. Have you got some magic to make it look good on both 480 and 320 wide screens ?

Our early preview does not do anything special for the varying screen sizes; however, this is something we are working through right now. The design(s) are not fully flushed out, but we are considering having pre-defined UI configurations (media queries, etc) baked-in for the well-known device resolutions. This would allow us to automatically alter things like the shell/navigation UI to work well on the given device. Again, the design is still in its early stages but working well on a variety of screen sizes is one of our highest UX-related priorities at this point.

I am afraid not. JQM does adress a lot of the browser-specific aspects of mobile development, but it does not provide any controls or UI patterns that specifically deal with varying screen sizes. I think Bill's main point here is that there are likely different patterns or constructs you'd want to use on a wide-screen tablet versus a narrow phone. Any logic to adapt to these different sizes would need to take place at the application layer–i.e., above jQuery Mobile–because the best UI for a given resolution is going to depend on the nature and content of the app.

I am impressed by the availability of HTML Client and want to try LightSwitch for enterprise apps development. Sorry if I am sounding naive, but can LightSwitch HTML Client be used for regular Web Development? I understand that it can be used for "devices", but will it cover desktop browsers? I am guessing, practically we could, but is it a product use case?

The save process is not intuitive. There should be no need for a second click. Also I note there is no prompt if user navigates away without a save. So the user "checks" then does not save, navigates away then returns to see the last entry is omitted. This should be changed.

You are so awesome! I don’t think I’ve read a single thing like that
before. So great too discover another person with original thoughts
on this topic. Seriously.. many thanks for starting this up.
Thhis web site is one thing that’s needed on the web, someone with a bit of originality!