locked
Will the RTM version of "HTML Client" support Desktop Browsers? RRS feed

  • Question

  • Hello Team;

    As the title says, will we be able to build HTML apps for desktop browsers as well as Mobile/Tablet when the "HTML Client" update goes RTM? Or will it be ONLY for Mobile?

    Thanks!


    ..Ben

    Thursday, December 6, 2012 1:09 AM

Answers

  • Hi All,

    Before delving into a specific response to the pervasive “Desktop” question, let me first state that the team has benefited tremendously from the discussion you have engendered on this thread and others in this forum.  (There have been several, “What do you think of that forum post…” chats internally lately.)  Please don’t take our delayed response as reticence: we've been listening.

    In terms of support for the desktop, the most honest answer I can offer is “your mileage may vary,” meaning that some applications built with the LightSwitch HTML client will be run well in a desktop context (i.e., mouse and keyboard), whereas other, “richer” user experiences may be impaired by our use of touch-first UI and reliance on modern web idioms.  Our client is really intended for mobile scenarios first and foremost. While have not focused our efforts on enabling desktop scenarios to date, you may find it reasonable enough for your needs—just recognize that you’re straying beyond the application’s intended target.

    The term “desktop” carries a range of connotations; let me try to break down the facets of “desktop support” and describe where we stand on each:

    The technical: Does the app actually run on desktop browsers?

    The desktop landscape is comprised of a very broad spectrum of browsers.  And unfortunately for all of us, some of the oldest and most problematic browsers from a development perspective are also the most widely used, particularly in situations where users are on older OS’s.  Building a rich, modern application with web technologies that runs on the myriad of desktop browsers is a sizable endeavor: enter the realm of varying standards support, reams of browser-specific code, and lowest-common-denominator user experiences.

    The value LightSwitch provides as a development tool rests in our ability to make the most relevant business application scenarios the easiest to build.  As such, we made a conscious decision not to target browsers that are decreasingly relevant—the return on investment was just too small. In other words, if you’re faced with building an application that must run on legacy browsers, the LightSwitch HTML client is not a viable option. But if your application will run in an environment where you can assume a reasonably recent browser will host your app, the HTML client might be sufficient for your needs. Internally, we test the apps on pretty much every “major” desktop browser that’s been released in the last year or two.  (We’re finalizing the exact list of supported browsers right now and we’ll publish it with the next HTML client update.)

    The UI: what are we doing to target a broader set of screen sizes?

    Desktop machines typically support much larger resolutions, and UI that looks great on a 320 px phone will seem a bit awkward running on your dual monitor, high-definition machine.  Since preview 2, the team has focused on an improved story for visual scalability, enabling the UI to change in accordance with the ambient view port size.  So you will see some subtle differences in things like font and icon sizes, layout, etc if you run the app on your phone and then on a large tablet.  But… we haven’t done any work to make the app scale to very large screens because even the densest tablet displays report modest resolutions in the browser—and again, mobile is really our target right now.

    Moreover, the HTML client is always based on JQueryMobile and our theme still honors the basic UI sizing parameters of touch-oriented apps.  But what makes our controls easy to touch with your finger also hinders its ability to create information-dense applications—the padding necessary to make an element touchable is increasingly problematic as you put more elements on the screen.  And while you can override our JQueryMobile theme, modifying the spacing and size of each control and layout is an exercise in frustration.  (Believe me, I’ve tried!)

    In short, if you need to create a desktop that’s information dense, the HTML client probably isn’t your best bet.

    The User Model: Can I build a MDI app?

    The user model is probably the most discernible difference between desktop and mobile apps: A desktop application traditionally supports concurrent user tasks and a user-directed workflow, whereas the smaller display of a mobile device often translates to apps tailored to discrete, guided user tasks. A desktop might stay open for days, whereas most mobile devices suspend or kill applications after a few seconds of inactivity.  As such, concurrent tasks and MDI-style user models are very rarely seen in mobile applications; our default shell and user model is reflective of that trend.  We expect users to traverse a graph of information until they find what they need; then they either move back in the graph or take action on one or more pieces of information—the model is loosely referred to hub-and-spoke by UX-types.

    The HTML client’s single task-orientation is more than just a user interface concept.  If you’ve had a chance to dig under the hood you may have noticed that there is just one data context for the entire app, whereas the Silverlight client supports a separate data context for each open screen.  Concurrent tasks require concurrent data change tracking, client side change set merging (i.e., make a change on one screen and see it on another), and a user model that describes concurrent, asynchronously executed tasks; and the HTML client does not support that.

    If you seek to build a user experience with concurrent task flows, the Silverlight client is a much better option.

    In response to some of the other topics that have cropped up here and on the blog (Sorry Ben!  Just saw your comments now.)

    -          Performance/SPA: We are dynamically creating these pages and have a disposal model to deal specifically with the issues inherent in SPA you’ve described.  I think we’ll need to carve out another blog entry on just this topic, though—it’s more than I can articulate here

    -          Desktop-specific support: We are not expanding the HTML client’s scenario target to include desktop in our first formal release.  The first release will be based exclusively on JQueryMobile and be optimized for building touch-oriented apps.  We’ll stay tuned to your feedback to sort out where/when we go after that, but we still have some issues to sort out for our mobile story and we’ll remained focused until we feel confident that we have a viable mobile offering.

    I hope this helps clear up some of the confusion.  Please feel free to respond with your follow-up and I’ll chime in.  (Most of us are out for the next week but we’ll respond in the new year.)

    As always, we really appreciate your support and the time you’ve taken to ask questions and extend feedback to the team.

    Joe

    Saturday, December 22, 2012 12:40 AM

All replies

  • Hi Ben,

    Is there specific support that you are looking for with desktop browsers that the product doesn't support today? Lightswitch itself is not limiting its usage to Mobile/Tablet only. A lot of the focus of the controls has been for touch usage but should still be able to be manipulated through keyboard/mouse.

    -Pierson

    Thursday, December 6, 2012 2:13 AM
  • Hi Pierson;

    From the first preview and I was the first to raise the question on Desktop availability, I got the impression that, this release (HTML Client) was geared towards Mobile/Tablet than full Desktop. I'm not unhappy that the focus has been to support the mobile, but the real question is, is this version equally as good on desktop? This [to me] has been kind of cloudy.

    So, could someone from the team, confirm that this version supports both Desktop and Mobile?

    And if the answer is yes, can we assume a user can run the HTML version without having the SL plugin? The whole idea is to replace the SL version with HTML version.

    Thanks!


    ..Ben

    Thursday, December 6, 2012 2:25 AM
  • Hi Ben,

    I will see if I can get confirmation about the dual support. I know that the HTML version will run without the SL Plugin. They are standalone clients.

    -Pierson

    Thursday, December 6, 2012 2:31 AM
  • Pierson, I'd greatly appreciate if you can confirm the dual support. This will be very important for us, if it does.

    Another question that I have, does the HTML version have a built in "Async Upload" widget?

    Thank you in advance!


    ..Ben

    Thursday, December 6, 2012 2:42 AM
  • You know, as I'm reading through this Blog, I have to agree with you that [as of Preview 2] there is no difference between the desktop and mobile version. This sounds real good. But your confirmation is still welcomed.

    Thanks!


    ..Ben

    Thursday, December 6, 2012 3:37 AM
  • Hey Ben,

    I'm giving this a try by porting one of our apps to P2.

    Our group at Vanguard has been thinking that we can pretty much "trim" down the size of Desktop screens to be 1024 X 768 which is what most open tablets have as their resolution (although some 7" tables are slightly smaller).

    Point being, we can get by with smaller screens so that one size is designed for both the Desktop and tablets.  Then we would create a smaller limited subset of screens for phones.

    Doing this we should be able to have just 2 sets of HTML Views to run our apps on all devices.

    I'll let you know how this works out.


    Garth Henderson - Vanguard Business Technology

    Thursday, December 6, 2012 4:08 AM
  • Garth, good to see you.;

    Yes, that's the why I'm approaching all my designs with 1024x768 for Desktop and generic tablets and Mobile size HTML for Mobile.

    Just FYI, your viewing width should be 960px, that's what everyone uses for the 1024 with screens.

    Keep me posted with private email. Thank you for info.

    Here is a picture to show the 960 px.


    ..Ben

    Thursday, December 6, 2012 4:53 AM
  • Thanks for the info, Ben.   Is the height 768 or smaller?

    On desktops, we are thinkng that we can have a frame (shell) that shows multiple screens.


    Garth Henderson - Vanguard Business Technology

    Thursday, December 6, 2012 5:53 PM
  • Thanks for the info, Ben.   Is the height 768 or smaller?

    On desktops, we are thinkng that we can have a frame (shell) that shows multiple screens.


    Garth Henderson - Vanguard Business Technology


    The height is dynamic. After the top header and menu rendered, the white area is the where the "Content" area is and I usually set it as "min-height: 500px". This way it fills the browser before the vertical scroll-bar shows up. But he width of 960 is important to stay common with most tablets and low end monitors.

    ..Ben

    Thursday, December 6, 2012 7:40 PM
  • Hey guys,

    I realize you (we) are looking for an official answer from the LS team, but I will add my view as well. 

    There are two reasons (which I think you already know) why I think the current HTML client (and presumable the RTM version) will not be suitable for desktop browsers, unless the LS team has a surprise up their sleeves:

    1) it is based on JQuery Mobile which is not really suitable for desktop based LOB applications.

    2) although based on an SPA (Single Page Application) client architecture, it has an SDI interface which means you will not be able to get the rich MDI interface that we currently have in the Silverlight client.

    The new server context that has been added into Preview 2 will make it possible to develop other ASP.NET based applications on top of the LS framework, and although potentially very useful in some scenarios, I do not think that is a substitute for being able to create screens inside the LS screen designer, which for me, at least, is one of the biggest LS advantages. 

    Regards


    Xander

    Thursday, December 6, 2012 8:48 PM
  • Hey guys,

    I realize you (we) are looking for an official answer from the LS team, but I will add my view as well. 

    There are two reasons (which I think you already know) why I think the current HTML client (and presumable the RTM version) will not be suitable for desktop browsers, unless the LS team has a surprise up their sleeves:

    1) it is based on JQuery Mobile which is not really suitable for desktop based LOB applications.

    2) although based on an SPA (Single Page Application) client architecture, it has an SDI interface which means you will not be able to get the rich MDI interface that we currently have in the Silverlight client.

    The new server context that has been added into Preview 2 will make it possible to develop other ASP.NET based applications on top of the LS framework, and although potentially very useful in some scenarios, I do not think that is a substitute for being able to create screens inside the LS screen designer, which for me, at least, is one of the biggest LS advantages. 

    Regards


    Xander

    Xander, you brought up two valid points. The first based on jQuery Mobile was my first info during P1 which I originally posted if it's really suited for desktop and why they even call it "HTML Client" vs. "HTML Mobile". So I figured by RTM they probably going to add routines in the architecture to recognize the browser and switch views accordingly. I have given them the benefits of the doubt.

    I have done some work on SPA and it's real life in LoB apps.

    Let's step back for a moment. In SL, we built many pages in the project (XAP). The pro part was that each page was independent and at runtime we could switch and load each page from memory rather than server. The Con part was that, the user had that initial wait for the XAP to load. Not a big deal or you could split it in multiple XAP.

    In ASP (WebForm or MVC) you have unlimited pages/views you can create and they get loaded from the server per demand. Pro part is that, no limitation and quick start up. The con part that there a small delay for each page.

    In SPA, you basically create all your pages into one page and have a "Logical" break for each page, but you load everything in DOM and then manipulate the DOM what shows and what hides. The Pro part is that, it's very fast to user because you just turn things off and on. The Con part is that, you have to load a lot of stuff into DOM and browser's memory and for LoB that may need 200 views for the project, you become limited, unless you go into the hybrid mode of Multi physical SPAs which becomes hard to maintain and move stuff around.

    *IF* LS is doing the HTML Client purely as SPA, it could carry a lot negative bags along with it. It would be best to follow the MVC architecture but with the benefits of LS for creating UI that ASP MVC doesn't have. SPA is sexy, but a big price to pay. I really don't know anything about the architecture of LS HTML Client.

    Just my 1.5 cent! :-)


    ..Ben

    Thursday, December 6, 2012 9:56 PM
  • I'm currently a follower, rather than a practitioner of SPA, so my knowledge is currently based on what a read about the various SPA frameworks.

    It is my understanding however, that the memory (and potential load time) problems that you refer to above can be overcome via "just in time partial views" loaded from the client as and when required. That does not mean you can open unlimited tabs/windows/screens of course as eventually you will run out of resources.

    I like the Silverlight MDI concept of opening multiple screens/tabs - it works well with most LOB applications and I would actually like the exact same concept in the HTML version that supports desktop browsers, whether SPA or otherwise.

    Using a client-side SPA architecture, I can see how it should not be too hard to have a data workspace per screen/tab in the same was as it is done in Silverlight today.

    ps. As mentioned in the other big desktop thread, I've seen a number of posts on the net about tweaking JQuery Mobile CSS to work in a desktop browser, but none that I've seen were successful.

    Regards


    Xander

    Thursday, December 6, 2012 10:10 PM
  • I'm keeping an open mind and positive hope for this new version that can server both Desktop & Mobile equally well for each platform accordingly without hacking. This will be LS Version 3. :-)


    ..Ben

    Thursday, December 6, 2012 10:22 PM
  • Hi Ben,

    I will see if I can get confirmation about the dual support. I know that the HTML version will run without the SL Plugin. They are standalone clients.

    -Pierson

    Hello Pierson;

    Did you find out any answer to the question or confirmation from the team?

    Thanks!


    ..Ben

    Wednesday, December 12, 2012 4:32 PM
  • Hi Ben, I forwarded the request to a PM on the team. He told me he is in the process of writing a blog to answer this question and will post here when he has it completed. Thanks Pierson
    Wednesday, December 12, 2012 6:06 PM
  • Hi Ben, I forwarded the request to a PM on the team. He told me he is in the process of writing a blog to answer this question and will post here when he has it completed. Thanks Pierson

    Excellent, Thanks!

    Looking forward to it. What's the name of the PM, so I keep an eye on blog?

    ..Ben

    Wednesday, December 12, 2012 8:47 PM
  • Should be Joe. Blog is the team blog at: http://blogs.msdn.com/b/lightswitch/

    Thanks

    Pierson

    Thursday, December 13, 2012 7:30 PM
  • Should be Joe. Blog is the team blog at: http://blogs.msdn.com/b/lightswitch/

    Thanks

    Pierson

    Thanks; Just read his Skin composition article and made a comment. He is a great communicator.

    ..Ben

    Thursday, December 13, 2012 8:05 PM
  • A clear statement on this would be helpful to many.   We're about to make some project decisions, and I'd sure love to have them include LS.  Key to it for us is HTML project generation that runs on a desktop browser and doesn't have SL as a pre-req.     Hoping for a positive answer.
    Thursday, December 20, 2012 12:50 PM
  • Hi All,

    Before delving into a specific response to the pervasive “Desktop” question, let me first state that the team has benefited tremendously from the discussion you have engendered on this thread and others in this forum.  (There have been several, “What do you think of that forum post…” chats internally lately.)  Please don’t take our delayed response as reticence: we've been listening.

    In terms of support for the desktop, the most honest answer I can offer is “your mileage may vary,” meaning that some applications built with the LightSwitch HTML client will be run well in a desktop context (i.e., mouse and keyboard), whereas other, “richer” user experiences may be impaired by our use of touch-first UI and reliance on modern web idioms.  Our client is really intended for mobile scenarios first and foremost. While have not focused our efforts on enabling desktop scenarios to date, you may find it reasonable enough for your needs—just recognize that you’re straying beyond the application’s intended target.

    The term “desktop” carries a range of connotations; let me try to break down the facets of “desktop support” and describe where we stand on each:

    The technical: Does the app actually run on desktop browsers?

    The desktop landscape is comprised of a very broad spectrum of browsers.  And unfortunately for all of us, some of the oldest and most problematic browsers from a development perspective are also the most widely used, particularly in situations where users are on older OS’s.  Building a rich, modern application with web technologies that runs on the myriad of desktop browsers is a sizable endeavor: enter the realm of varying standards support, reams of browser-specific code, and lowest-common-denominator user experiences.

    The value LightSwitch provides as a development tool rests in our ability to make the most relevant business application scenarios the easiest to build.  As such, we made a conscious decision not to target browsers that are decreasingly relevant—the return on investment was just too small. In other words, if you’re faced with building an application that must run on legacy browsers, the LightSwitch HTML client is not a viable option. But if your application will run in an environment where you can assume a reasonably recent browser will host your app, the HTML client might be sufficient for your needs. Internally, we test the apps on pretty much every “major” desktop browser that’s been released in the last year or two.  (We’re finalizing the exact list of supported browsers right now and we’ll publish it with the next HTML client update.)

    The UI: what are we doing to target a broader set of screen sizes?

    Desktop machines typically support much larger resolutions, and UI that looks great on a 320 px phone will seem a bit awkward running on your dual monitor, high-definition machine.  Since preview 2, the team has focused on an improved story for visual scalability, enabling the UI to change in accordance with the ambient view port size.  So you will see some subtle differences in things like font and icon sizes, layout, etc if you run the app on your phone and then on a large tablet.  But… we haven’t done any work to make the app scale to very large screens because even the densest tablet displays report modest resolutions in the browser—and again, mobile is really our target right now.

    Moreover, the HTML client is always based on JQueryMobile and our theme still honors the basic UI sizing parameters of touch-oriented apps.  But what makes our controls easy to touch with your finger also hinders its ability to create information-dense applications—the padding necessary to make an element touchable is increasingly problematic as you put more elements on the screen.  And while you can override our JQueryMobile theme, modifying the spacing and size of each control and layout is an exercise in frustration.  (Believe me, I’ve tried!)

    In short, if you need to create a desktop that’s information dense, the HTML client probably isn’t your best bet.

    The User Model: Can I build a MDI app?

    The user model is probably the most discernible difference between desktop and mobile apps: A desktop application traditionally supports concurrent user tasks and a user-directed workflow, whereas the smaller display of a mobile device often translates to apps tailored to discrete, guided user tasks. A desktop might stay open for days, whereas most mobile devices suspend or kill applications after a few seconds of inactivity.  As such, concurrent tasks and MDI-style user models are very rarely seen in mobile applications; our default shell and user model is reflective of that trend.  We expect users to traverse a graph of information until they find what they need; then they either move back in the graph or take action on one or more pieces of information—the model is loosely referred to hub-and-spoke by UX-types.

    The HTML client’s single task-orientation is more than just a user interface concept.  If you’ve had a chance to dig under the hood you may have noticed that there is just one data context for the entire app, whereas the Silverlight client supports a separate data context for each open screen.  Concurrent tasks require concurrent data change tracking, client side change set merging (i.e., make a change on one screen and see it on another), and a user model that describes concurrent, asynchronously executed tasks; and the HTML client does not support that.

    If you seek to build a user experience with concurrent task flows, the Silverlight client is a much better option.

    In response to some of the other topics that have cropped up here and on the blog (Sorry Ben!  Just saw your comments now.)

    -          Performance/SPA: We are dynamically creating these pages and have a disposal model to deal specifically with the issues inherent in SPA you’ve described.  I think we’ll need to carve out another blog entry on just this topic, though—it’s more than I can articulate here

    -          Desktop-specific support: We are not expanding the HTML client’s scenario target to include desktop in our first formal release.  The first release will be based exclusively on JQueryMobile and be optimized for building touch-oriented apps.  We’ll stay tuned to your feedback to sort out where/when we go after that, but we still have some issues to sort out for our mobile story and we’ll remained focused until we feel confident that we have a viable mobile offering.

    I hope this helps clear up some of the confusion.  Please feel free to respond with your follow-up and I’ll chime in.  (Most of us are out for the next week but we’ll respond in the new year.)

    As always, we really appreciate your support and the time you’ve taken to ask questions and extend feedback to the team.

    Joe

    Saturday, December 22, 2012 12:40 AM
  • Joe, it's always a pleasure reading your posts and replies, even when they don't have great news, but they're honest and full of meaningful content. This way we can plan and adjust out strategy according to the development.

    I'm going to hold my judgement until we see the RC or RTM and then decide if it will fit the bill.

    However, I actually think it's best to use WebForm or MVC to tackle the "Desktop" and somewhat legacy browsers and then share same backend data with LS for Mobile. It's funny, every product starts with Desktop version first and then converts it to Mobile (we're talking HTML now), but you guys did it for Mobile first. So, if the LS Mobile turns out to be a strong product, then we can mix it with MVC for desktop. Just an idea.What your "rough" time frame for RTM? Is Mid year reasonable?

    Thanks Joe for the rich reply!
    Happy Holidays!


    ..Ben

    Saturday, December 22, 2012 1:27 AM
  • Many thanks to Joe Binder for his post-apocalyptic 12/22/12 information.  It turns out that last Saturday was, thankfully, a very normal day for all of us.

    It is clear that we need a universal phone interface.   This we will get with the HTML release.

    On 12/21/12, I was able to migrate an existing VS 2012 app to P2 and create a prototype phone app that ran on my Windows 8 phone and my wife's iPhone 3 using the existing apps Data Source services.   I really like what LS has done to make phone app development easy.

    The middle platform is the pad/tablet HTML5 touch devices.  This thread has discussed that it is reasonable to merge the desktop and pad/tablet screen formating into a single platform with HTML5 using jQuery. 

    The desktop and tablet platform would have separate LS shells - but otherwise share the same Screen definitions.

    Windows 8 supports both touch and mouse/keyboard UIs.  

    Questions: 

    1) Isn't jQuery technology designed to concurrently support both mouse/keyboard and touch commands?

    2) Isn't jQuery Mobile built on jQuery?

    3) Don't we already know what to expect in building apps that support both desktops and tablets?

    4) Don't we expect to see phones (like Win 8) connected to a larger monitor, keyboard, and mouse to function like a tablet/desktop?  In which case, the user would simply access the web site with the tablet/desktop View app.

    5) Can't we currently build MVC apps with HTML5 RIA GUI that access our LS Data Source (OData) Services?


    Garth Henderson - Vanguard Business Technology


    Wednesday, December 26, 2012 10:14 PM
  • > In other words, if you’re faced with building an application that must run on legacy browsers, the LightSwitch HTML client is not a viable

    For the sake of this discussion, what constitutes a Legacy Browser?

    What if I said that my customer browser set is: IE 8 or above, as well as the latest Chrome and the latest Safari?   Would we then be ok on a Silverlight-less desktop browser?

    Friday, December 28, 2012 9:06 PM
  • Hi All,

    Thanks for the good discussion; here's some follow-up on your questions:

    From Garth:

    1) Isn't jQuery technology designed to concurrently support both mouse/keyboard and touch commands?

    Yes, you can certainly use your mouse and keyboard to interact with the LS HTML client and--more generally--JQueryMobile applications.  The issue is not really whether or not the app will work but whether it will work *well* with a mouse and keyboard; and we do test that regularly.  The "Your mileage may vary" assessment is more directly related to the amount of information you can put on the screen.  The controls are necessarily larger and have more space between them to support touch interaction, so it's much harder to achieve information density.

    2) Isn't jQuery Mobile built on jQuery?

    Yes, although jQuery and jQueryMobile are different types of frameworks.  jQuery is a utility library for interacting with the DOM, whereas jQueryMobile is an application framework with its own navigation model, theme conventions, and control model--it entails a higher level of abstraction and its own unique concepts that compose the application.  The frameworks serve very different purposes: jQuery mitigates the need to write browser-specific DOM manipulation code and jQueryMobile provides building blocks for composing a mobile application. 

    3 & 4) Don't we already know what to expect in building apps that support both desktops and tablets?

    I think it's very reasonable to assume that developers will need to recognize the need to support the range of devices moving forward--from a tiny phone to a large desktop.  What remains to be seen, however, is a single application implementation that serves all of these roles well. Some of the issues here are technical, but most are rooted in different use cases that emerge for each device classification.  The app you want to use walking to the bus station in the morning likely serves very different roles than the app you use at your desk for hours on end.  We spent some time talking with and researching phone apps that grew to support tablets and one of the key findings was that those that simply scale the applications UI without scaling the underlying scenarios were almost universally poorly ranked. 

    All that said, we certainly view the need to build an application that runs well on all device/desktop form factors a reality; we just see the means by which one might do that a little differently.  Our early thinking here is that there are many assets in a LightSwitch project that are universally useful and you would want to use on all devices: the data model and middle-tier logic are obvious, but we also view client-side logic--entity events, etc--to be something you wouldn't want to recreate for each client-side experience you build.  Maybe you want your home and list-based screens to be denser on the desktop (e.g., use a data grid/list view on the desktop and a tile list on the phone ) but keep the information density of your details screens more or less the same in all cases?  (It's pretty easy, for example, to layout a basic edit form such that it's usable on a desktop and phone using wrap/flow semantics.) We're including a few low-level hooks in the next HTML client release to make some of this possible, and I'd appreciate your feedback when it becomes available.


    5) Can't we currently build MVC apps with HTML5 RIA GUI that access our LS Data Source (OData) Services?

    Yes, absolutely.  MVC + LightSwitch is an effective approach to building a custom client that's backed by your LS service.  This technique includes some heavy lifting, but it's certainly viable.  

    6) What constitutes a legacy browser? 

    IE 8, for example, would be considered a legacy browser in our vernacular. The subsequent two releases of IE made huge strides to support HTML5/CSS3 conventions. IE 8, in contrast, lacks support for a number of key constructs that our apps require, such as touch events.  We hope to have our browser matrix finalized in the next few weeks here,  and I will update this post as soon as it's available.  

    Thanks,

    Joe


    Wednesday, January 2, 2013 7:00 PM
  • Many thanks to Joe for his information.

    Here's my thoughts in light of Joe's info:

    The jQueryMobile implementation in LS is exactly what is needed.  It is designed for the handheld small phone form factor. 

    Tablets (and Phones) have the option to support web pages.  For example, we can use the SSRS report viewer with a phone. 

    Similarly, using a stylus with phone apps should be an option to support tighter forms entry with the smallest form factor.   Consider that we currently need to use a stylus to get signatures for Point of Sale phone apps.

    Yes, the industry needs a standard (consensus) HTML solution that supports tablets and desktops with viable options for touch and/or mouse/keyboard.  There are several existing projects that are attempting to provide solutions to a universal UI - no clear winner yet.  

    jQuery has a family of projects:

    http://jquery.org/

    jQuery Mobile is addessing virtual mouse events and are covering touch tablets.  The current release of jQuery Mobile was 10/2/12 with 1.2.0:

    http://jquerymobile.com/blog/2012/10/02/announcing-jquery-mobile-1-2-0-final/

    Infragistics IgniteUI is a commercial HTML5 "Toolset for any Browwer, Platform, or Device":

    http://www.infragistics.com/products/jquery/

    It looks like it has a full set of components. 

    Similarly jQWidgets as their own set of components:

    http://www.jqwidgets.com/jquery-widgets-demo/

    Component One, Telerik, DevExpress also have HTML compoent sets . . . and there are more.

    What would we have to change within LightSwitch or within these commercial component sets to work together without a lot of "heavy lifting?"

    What Joe wrote (above) comes to mind:

    • MVC + LightSwitch is an effective approach to building a custom client that's backed by your LS service.  This technique includes some heavy lifting, but it's certainly viable. 

    The universal connecting point is the LS OData Web Service - regardless of whether it is with MVC or commercial HTML component sets.

    hmmm . . . .


    Garth Henderson - Vanguard Business Technology


    Thursday, January 3, 2013 1:44 AM
  • Hi Garth,

    I will muddy the waters a bit by saying that--in addition to the specific vendor projects you've referenced--most of our partners are now investing in pure client-side, JavaScript-based control libraries.  (See, for example, Kendo UI from Telerik and Wijmo from ComponentOne as two good examples.) These libraries can of course be used in MVC views, too, but they don't rely on any server-side rendering.  It's worth taking a close look at frameworks of this variety because they require a much looser contract to function--often one needs to just to describe the basic shape of the client-side view model to wire-up the control. Some, such as wijmo, are pre-trained to work with specific view model frameworks, such as knockout. You can also point the controls at the LS odata service directly, but there are some considerable advantages to using the controls in conjunction with the LightSwitch view model.

    In many respects, these emerging frameworks exemplify the power and flexibility of JavaScript: whereas .NET control libraries often required specific view model implementations or data service contracts, JavaScript-based controls need only know that a property of a specific name is present in order to databind.  Longer term, we'd like to have control frameworks of this sort to "just work" inside LightSwitch; but in the meantime, you might take a look at the frameworks referenced to understand whether or not using the LS dataworkspace in conjunction with something like knockout is less work than binding to the oData service directly.  Again, your mileage may vary--I just thought I'd mention it as something to consider in the near term.

    As an aside, I have recently built some clients that use jQuery UI and knockout in conjunction with the LightSwitch data workspace--it's something I hope to blog about one of these days as a companion to Michael Washington's excellent post(s) on using the "raw" LS oData feed in conjunction with knockout. Both approaches work pretty well: the former requires less heavy lifting because LS handles all of the client-side data loading, modeling, and changeset tracking; but the "raw" approach Michael describes affords you much more flexibility.

    In short, the suggestions and observations you've called out are very much on our radar. We're presently exploring all of them in some capacity.

    Thanks.

    Joe

    Thursday, January 3, 2013 4:07 AM
  • Thanks so much for your additional information.  The fact that jQuery UI requires less hand coding is very useful to know.  

    http://jqueryui.com/

    Unless I'm missing something, jQueryUI doesn't have a Grid component.  That is pretty much the heart of a biz app.

    RE:  " . . . there are some considerable advantages to using the controls in conjunction with the LightSwitch view model."

    That is definitely the logical goal for RAD HTML development.

    Has the LS Team provided enough information about LS P2 to use jQuery compatible 3rd party components sets with the LS View Model?

    If so, it might make sense for us to do a prototype and approach one or more vendors with an integration opportunity. This certainly would be a win/win opportunity.


    Garth Henderson - Vanguard Business Technology

    Thursday, January 3, 2013 5:38 AM
  • Unless I'm missing something, jQueryUI doesn't have a Grid component.  That is pretty much the heart of a biz app.


    Garth Henderson - Vanguard Business Technology

    The ComponentOne Wijmo has a grid:

    I am working on a article hopefully next week...


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

    Thursday, January 3, 2013 6:07 AM
  • Thanks, Michael.  

    I'd like to ask our friends to compare the IgniteUI, the Kendo, and the Wijmo grids:

    http://www.infragistics.com/products/jquery/grid/

    http://demos.kendoui.com/web/grid/index.html

    Here is the ComponentOne Grid:

    http://wijmo.com/widgets/wijmo-complete/grid/

    Having used commercial controls for a few years with Windows, Web, WPF, and Silverlight platforms, the grids offered by Infragistics and Telerik for HTML match the functionality and professional desktop UI that ERP / LOB users are expecting in a top-of-the-line business application.

    LS needs to support commercial HTML controls of this caliber using the "considerable advantages to using the controls in conjunction with the LightSwitch view model." (as Joe points out).

    Please keep in mind that we've been supporting the tablet form factor for several years with touch using these professional component sets.  Yes, the HTML touch environment is much more wonderful than the previous touch capabilities.  I love Windows 8 Desktop and Windows 8 Phone.  With HTML and a professional component suite for both phone and tablet/desktop, we'll be able to knockout (all puns intended, of course) great looking LS RAD apps in record time.  

    LS will allow MS developers to quickly eclipse existing mobile app markets and to radically extend legacy LOB / ERP systems - which will boost global business, especially within the small and medium sized business groups.

    All we need is an LS hub with the necessary wrappers to wire in the HTML commercial components of our choice.

    What more do we need to know about LS P2 in order to access the "considerable advantages to using the controls in conjunction with the LightSwitch view model?" (as Joe points out).

    Michael, you've done more than anyone in our community to pioneer the wonderful world of HTML with LS.  Your technical project blogs have done much to evolve our world of business app development.  We all thank you!

    Will your next HTML project with Wijmo controls show us how to take advantage of the LightSwitch view model to eliminate the "heavy lifting" (or as I've always called it: "monkey coding")?


    Garth Henderson - Vanguard Business Technology

    Thursday, January 3, 2013 6:32 PM
  • Garth, before really making any decisions, let's wait for the RC or RTM version of LS to see which one of these products has a better "Integration" with LS. Just because one might be a great product as "Stand-alone" doesn't mean it works well in "Integration" mode.

    Secondly, I suggest to keep this on the list http://www.jqwidgets.com/ The team is very focused on ONE product.

    RTM, will provide many things that we need to make decision on.


    ..Ben

    Thursday, January 3, 2013 6:51 PM
  • Will your next HTML project with Wijmo controls show us how to take advantage of the LightSwitch view model to eliminate the "heavy lifting" (or as I've always called it: "monkey coding")?


    Garth Henderson - Vanguard Business Technology


    Yes, I will demonstrate full CRUD and the code required to make it work with LightSwitch data is very minimal.

    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

    Thursday, January 3, 2013 8:07 PM
  • Wonderful!  Thanks, Michael.

    Garth Henderson - Vanguard Business Technology

    Thursday, January 3, 2013 8:40 PM
  • Garth, before really making any decisions, let's wait for the RC or RTM version of LS to see which one of these products has a better "Integration" with LS. Just because one might be a great product as "Stand-alone" doesn't mean it works well in "Integration" mode.

    Secondly, I suggest to keep this on the list http://www.jqwidgets.com/ The team is very focused on ONE product.

    RTM, will provide many things that we need to make decision on.


    ..Ben

    Thanks, Ben.  jQWidgets is on my list.

    Here's the link to the jQWidgets Grid:

    http://www.jqwidgets.com/jquery-widgets-demo/demos/jqxgrid/index.htm

    Since my livelihood currently depends on LS, I have a vested interest in making sure that LS RTM will support what we need for HTML clients using well supported, great looking commercial component suites.

    I greatly appreciate what Michael and Joe are doing to support HTML component sets with LS.

    I will soon be releasing some helpful P2 Mobile apps for our users.  These apps are NOT mission critical and I won't fuss too much if they have to be rewritten when a production supported release of HTML is available.

    Likewise, I will also take Michael's example (and anyone else's example) and build a desktop/tablet prototype with P2 using a commercial component set to assure that Joe's goal of seamless integration with the LS View Model is achievable.   I will also seek out others in our community to share the load as we work toward having an HTML desktop ASAP.  Logically, we will create a consensus methodology to bridge the gap between tablet and desktop platforms with separate LS shells.

    I am very impressed with how far both Infragistics and Telerik have gone with their HTML component sets.   jQWidgets is very impressive as a smaller new company project.  jQWidgets is the most affordable robust set of components. 


    Garth Henderson - Vanguard Business Technology

    Thursday, January 3, 2013 9:07 PM
  • Interesting continuation of this discussion. From reading all the comments it appears to me that the HTML client is starting to get tweaks and hooks to allow screens to be potentially reformatted to better fit desktop browsers. I wonder how far we can push this.

    I would be happy to create multiple HTML clients: one targeting mobile devices and another targeting desktop browsers. I agree with sentiments expressed above that one size may not fit all devices.

    If we assume that we will be able to use one or all of the UI component frameworks mentioned above,  the last part of the puzzle remaining (also mentioned earlier in the thread) to create compelling SPA desktop HTML clients, in my opinion, is support for:

    1) allowing MDI clients in addition to the current SDI clients geared for mobile devices and

    2) the ability to instantiate multiple simultaneous workspaces running on the client

    To create compelling LOB desktop HTML clients in LS we need either support out of the box for these or have appropriate hooks to allow us to do that. This capability will allow us to create applications similar to what we can in the Silverlight version which I believe should be the goal.

    It is my understanding that the above will not be supported out of the box in the RTM version of the HTML client, but could support be added in time via hooks, etc to allow work-around solutions until this is supported in the next version?


    Xander

    Thursday, January 3, 2013 10:14 PM