Creating complex UWP apps is possible (with high density UI)

Avatar
70

I’ve read about Paul complaining that UWP is not making progress and can only be used to build “basic” apps.

As a UWP developer, I don’t understand that claim.

High density UI are possible. It is just a matter of sizing each button accordingly. For example:

https://www.actiprosoftware.com/products/controls/universal/docking

That’s a sample app that looks like Visual Studio (with all the UI features like moving windows, docking, tabs, etc).

It works on Windows 10’s first build (1507).

And UWP keeps becoming more and more powerful for edge cases. For example, it is now possible to launch a UWP app from the command line. So, it is possible to build console applications with UWP.

So, I would like to hear some specific examples of technical features that UWP lacks and that is blocking mainstream UWP developers.

Comments (70)

70 responses to “Creating complex UWP apps is possible (with high density UI)”

  1. Avatar

    safrane

    That sample illustrates well what a productivity app can look like. And that screenshot is indistinguishable from a Win32 app.

  2. Avatar

    jimchamplin

    Looks exactly like a WPF app. And with WPF, you don’t have to deal with async/await.

  3. Avatar

    Paul Thurrott

    This is a third party solution. Microsoft literally just announced "UI density" capabilities for UWP this week at Build.


    That said, point me to that one high profile, professional-looking (e.g. like Office or Photoshop) UWP app that disproves my real point. Which is that UWP apps suck.



    • Avatar

      lvthunder

      In reply to paul-thurrott:

      How would you know? There is no difference in a UWP, PWA, or Bridge app in the store. The one that comes to my mind that I think is UWP is OneNote.


      Also when was the last time a high profile, professional-looking (Office or Photoshop) app was started from scratch. Aren't both of those version numbers in the 20s.

        • Avatar

          lvthunder

          In reply to paul-thurrott:

          How would one know if an app is a UWP app or not? Someone gave an answer below, but it's so convoluted no one would care that much. It's hard if not impossible to find apps that have as many features as Office or Photoshop that are younger than UWP is. Those products have taken over 20 years to get all those features.

          • Avatar

            skane2600

            In reply to lvthunder:

            It's the ideas that took 20 years to develop, not the implementation. For example, Google Docs took many ideas developed over years from Microsoft Office but was able to implement them in a shorter time.

            • Avatar

              hrlngrv

              In reply to skane2600:

              . . . many ideas developed over years from Microsoft Office . . .

              Those ideas didn't spring newborn from the minds of MSFT developers.

              Software Arts was selling VisiCalc before MSFT had come up with Multiplan. Excel is only part Multiplan; there's considerable contribution from Lotus 1-2-3 (not least Excel's DCOUNT etc functions which remain mired in early 1980s functionality with respect to their 3rd arguments which even Lotus had radically improved by the late 1980s). Fortunately Google didn't copy those MSFT ideas (or would that be MSFT idea vacuum?).

              • Avatar

                skane2600

                In reply to hrlngrv:

                I wasn't implying that every idea embodied in Microsoft Office came directly from Microsoft. The lion's share of credit for the spreadsheet idea obviously belongs to Software Arts with the other companies building on it.


                I would argue though that creating a spreadsheet in a GUI with real vertical and horizontal lines was the single most important added feature that led to a wide adoption of spreadsheets (as is the case with the origin of any technology, it's difficult to say if MS was the very first to do this, but certainly the first to create a successful product using that technique).



                • Avatar

                  hrlngrv

                  In reply to skane2600:

                  Excel was a bit player in the workplace until Excel 5 and the advent of VBA. Spreadsheets had become widely used before that, and IIRC Ability Office's spreadsheet had horizontal and vertical lines bordering cells in the mid-1980s before there was a Windows version of Excel. (FWIW, Ability Office was a CGA/VGA quasi-GUI all-in-one suite.) What made Excel a success was the rise of Windows and the piss-poor first version of 1-2-3 for Windows and the lethargy of Borland coming out with a Windows version of Quattro Pro (though that first QPW version allowed users to change the color of worksheet tabs, a feature that took MSFT another 8 years to implement in Excel).

                • Avatar

                  skane2600

                  In reply to hrlngrv:

                  Congratulations on finding an obscure spreadsheet with lines that may predate the same on Excel. I say "may" because Excel had that feature on the Mac in 1985. I'll take your word that Ability had such a version in the 80s since I can't find a reference for it. The latest DOS version that is shown on Ability's website is a typical DOS spreadsheet without lines.


                  I'm not going to argue about relative sales figures of the 80s and 90s since that data isn't really available. We're now wildly off-topic,

                • Avatar

                  hrlngrv

                  In reply to skane2600:

                  We're on a UI tangent. My point is that Excel's column and row lines grid didn't in and of itself make Excel popular. Spend some time in Excel user-to-user support forums and you just might develop the impression those grid lines aren't that useful.

                • Avatar

                  skane2600

                  In reply to hrlngrv:

                  I doubt I'd get much insight into what made Excel popular by visiting forums that didn't exist at the time in question populated with many people who were children at that time.


                  But remember, my original point was just that the number of years it takes to evolve a application to create new functionality doesn't inform how long it takes new applications to implement that same functionality. I just used Microsoft Office vs Google Docs as one example.


                  I think we can agree that few if any features of Google Docs were original ideas and that it took a lot less time to implement than it took to come up with those ideas no matter where we want to assign credit.

          • Avatar

            hrlngrv

            In reply to lvthunder:

            . . . no one would care that much . . .

            Other than those of use responding in this thread. Be honest: you'd use convoluted means to prove me wrong, and I'd be happy to return the favor. Messing with file ownership and permissions is necessary if using only Windows bundled functionality. However, quite simple for those who need to use Administrator accounts regularly to use Process Explorer. I'd suspect every developer following this site knows what it is, and most have used it.

            Then there's your ending point: if it'd take XYZ UWP app 20 years to reach the functionality MS Office has today, where would Office be in another 20 years?

            I'll repeat something I've already written: new usually has to be better than old to have a chance of supplanting old. Is UWP sufficiently better than Win32 at complex, control-dense UIs?

      • Avatar

        skane2600

        In reply to lvthunder:

        "There is no difference in a UWP, PWA, or Bridge app in the store."


        Not sure what you mean by that. As hringrv points out, you can discover differences with some effort and I suspect many apps will self-identify in their description.



        "Also when was the last time a high profile, professional-looking (Office or Photoshop) app was started from scratch."


        Well, when was the last time this occurred on ANY platform? In any case, if new "high profile, professional-looking" programs are no longer being created, that really has nothing to do with relative desirability of developing for UWP.


        I think Paul's more important implication is that developers are going to hesitate to use third-party solutions (which may cost money or may not be supported in the future) to create an interface in UWP that they can do "out of the box" with Microsoft's tools for desktop development.



        • Avatar

          klients

          In reply to skane2600:


          I agree with you. To clarify: The examples I posted (like the app that looks like Visual Studio) are meant to be seen as proof of what UWP is capable of. I could build exactly the same thing without using third-party tools. It is not like they have some special magic sauce that is not available to all developers.

          • Avatar

            skane2600

            In reply to klients:

            Sure. Of course third-parties can't do anything that couldn't be done by the developer themselves. it's just of question of how much knowledge and effort is required. For example MS's introduction of Common Dialogs was a big time saver although it was always possible to program those dialongs "by hand".


            It's just that UWP's "out of the box" UI support is more focused on touch based UI elements than traditional Windows elements.

            • Avatar

              klients

              In reply to skane2600:


              If a dev team is working on a "high density" app, they will be investing a lot of time in all the features behind that app. The time that it takes to tweak the UI to be more compact will be negligible in comparison.

              • Avatar

                hrlngrv

                In reply to klients:

                . . . dev team is working on a "high density" app . . .

                MSFT has an ideal candidate: their own R Open. What an ideal candidate to show the full capabilities of UWP, able to handle computationally intensive back-end, able to interface with DBMSes, moderately complex UI. Yet the R Open team has shown no interest. Most benign reason may be that there are A LOT of users running R Open under Windows 7 and 8.1.

                Even if UWP could give Win32 a run for its money in control-dense UIs, until Windows 7 reaches EOS, there may be no point.

                I hate writing this, but it may be too early to tell. However, if there still aren't many control-dense UI UWP apps by 2022, then UWP would well & truly be dead whatever its capabilities.

              • Avatar

                skane2600

                In reply to klients:

                I think that's an assumption that in the general case isn't valid. Sometimes the UI is the most time-consuming part of the development with the "business logic" consisting of well-known algorithms. In any case, with today's rapid development any saved time shouldn't be considered "negligible" particularly when that time savings comes from a standard stock capability one doesn't have to maintain.

      • Avatar

        hrlngrv

        In reply to lvthunder:

        Tangent. Using an Administrator account take ownership of C:\Program Files\WindowsApps, then give the Administrators group permission to read all directories under it. UWP apps lack .EXE files, but packaged desktop software still have .EXE files. That's one way to confirm what's what. Or you could use Process Explorer or the like.

    • Avatar

      klients

      In reply to paul-thurrott:


      When I read your posts, I am looking to be informed. So, when you make a specific claim, I want to understand where that comes from. If we can agree that UWP is not such a limited platform, then, when discussing "UWP apps suck", we can look for the real reason.


      To reply to your specific comment:

      UWP is a platform to build apps. Whether they are "first party" or "third party" is irrelevant to the technical capabilities of the platform. (If a third party was able to do something, that proves my point even more than if it was done by Microsoft themselves.)


      The upcoming "compact sizing" feature is a standardized way to dynamically change the density of the UI. The core value is that, without this feature, most developers would choose one "sizing"/density, and stick to it.

      This is similar to having Dark theme be standardized. It was always possible to build an app with a black background and white text, but with theming, it encourages (and make it easy for) developers to support both Light and Dark themes.

      These are great time-savers for developers.

      • Avatar

        Paul Thurrott

        In reply to klients:

        My position, that UWP has resulted in a generation of childish-looking apps, is easily defended. What I've called on Microsoft to do is make aspirational apps for Windows 10, which its not done, and to give developers what they need to make professional apps of their own as well. These do not exist, almost literally, and the only professional-looking apps in the Store today are Desktop Bridge apps, which are Win32 desktop applications.

        Also, you've missed my point about third-party. This thing you're pointing to isn't a third-party app, it's a third-party control for developers. That something is technically possible with great effort (and expense) isn't the point. The point is that Microsoft should make more professional controls itself and make them available as part of the stock UWP toolkit. Point me to all the wonderful, command-rich UWP apps that were made with this control you're so happy about.

        I don't quite get the aggression or enmity here.

        • Avatar

          skane2600

          In reply to paul-thurrott:

          I agree. I also think that Microsoft has had trouble letting go of the mobile first, touch first, cross-platform philosophy that drove the original design of WinRT. Providing desktop-like controls would be an acknowledgement of their mistake and would make it easier to create UWP apps that can run only on a PC. Of course, UWP is already failed on other platforms, but this would be really throwing in the towel.


          But at the end of the day there's still the question: Why bother to recreate Win32 capabilities in UWP if they run only on the PC anyway?


        • Avatar

          klients

          In reply to paul-thurrott:


          The most time-consuming and costly part of complex apps is not the UI, it is the business logic behind it.


          I think that "childish-looking" apps had nothing to do with UWP technical capabilities specifically. Something similar happened with iOS and its fart apps, for example. I think it is because new platforms will naturally fill with simple apps first.


          Devs build (complex) apps as a business, so I would look first for what would make sense business-wise before blaming the technology.


          By the way, I found that third-party control because I'm working on a project that needed some of its features. And, in the end, I was able to replicate them alone in a single week. It really doesn't take "great" effort.


          Finally, I hope I wasn't being aggressive. I appreciate having deep factual conversations.

          • Avatar

            jimchamplin

            In reply to klients:

            "The most time-consuming and costly part of complex apps is not the UI, it is the business logic behind it."


            -- Anyone who thinks UI doesn't matter


            UI is the MOST important part of an application. Just because LOB software doesn't "need" good UI doesn't mean that real software, meant for people who get to choose it should be garbage.

          • Avatar

            hrlngrv

            In reply to klients:

            The most time-consuming and costly part of complex apps is not the UI, it is the business logic behind it. . . .

            You mean new in-house line of business apps? Lots and lots of in-house developers would find it worthwhile to take a few months to get up to speed on UWP?

            If you mean porting existing software, the desktop bridge would be a far more economical alternative. Also, the business logic is already well known, and if it takes considerable effort to port it from Win32 to UWP, UWP is again dead because uneconomical.

  4. Avatar

    doofus2

    After five years, the WinRT API (WinRT10/UWP) has finally begun to approach the capabilities of Win32. I haven't looked at the docs for several years so I don't know if they wised up and moved away from the idiotic Async fetish (which spreads like cancer throughout a project). Also, did they finally fix the two orders-of-magnitude difference in file system performance compared to Win32?

  5. Avatar

    klients

    To answer hrlngrv (for some reason, I can't post this as a reply):


    Yes, it is technically possible to create user-customizable toolbars in UWP.

    Here is a simple example: www.actiprosoftware.com/Content/Images/platforms/controls-universal/gallery/SyntaxEditorSDIEditor.png

    The Ribbon is just more of the same.


    AutoIt doesn't support .NET apps (incl WPF). They explicitly choose to not support them: www.autoitscript.com/forum/topic/80556-autoit-support-for-wpf-and-net-35-applications/?do=findComment&comment=673920


    But there are other automation tools like pywinauto that do: github.com/pywinauto/pywinauto


    • Avatar

      hrlngrv

      In reply to klients:

      Point remains: how much market is there for complex software which would only run under Windows 10?

      As far as I can tell from the MSFT Store's offerings, zero for statistical and mathematical software (excluding primary and secondary school educational software), zero for front-end tools for working with DBMSes, not much for developers. And while I have Code Writer installed and try using it from time to time, it's no substitute for Notepad++ or, when I need very involved edits, vim.

      If it has been possible to build software with complex UIs using UWP for a while, why is there so little on the market nearly 3 years after Windows 10 was first released? Maybe UWP's technical capabilities are comprehensive, but if no developers, not even MSFT itself, are using them, what does it matter?

      • Avatar

        klients

        In reply to hrlngrv:


        Like I said, the discussion here is not how successful UWP is as a business.


        Paul (and others) are claiming that the UWP platform is technically limited, and I wanted more details on that. As a software developer, I am curious about that.

        • Avatar

          klients

          In reply to hrlngrv:


          Here is the most recent comment from Paul (written a few hours ago):

          "I have been complaining about UWP UI density (which I called command density) for years..."

          twitter.com/thurrott/status/993885560665092096


          And I want to stay away from unsubstantiated claims/speculations.

          If we can't come up with an actual example of a limitation, then we can move the UWP conversation forward.

          • Avatar

            hrlngrv

            In reply to klients:

            . . . If we can't come up with an actual example of a limitation, then we can move the UWP conversation forward.

            Technical capabilities are nice, but capabilities vs difficulty of implementation trade-offs are equally important, at least from an engineering perspective. Some of any perceived difficulty using UWP would be due to developers' lack of familiarity compared to various Win32 approaches, but that's always the case with anything new. Tough luck for the new, but it usually has to be better than older, established approaches to gain appreciable uptake. Is UWP better?

            BTW, I don't use Twitter, so I have no idea what Paul Thurrott tweats.

  6. Avatar

    Daekar

    Sure looks like a useful UI to me...

  7. Avatar

    Bill Russell

    But small element, dense UIs are not universal. To be universal you would tend to keep at least a happy medium size, as you need to have the fat fingered touchscreen user in mind. Ironically, UWP is about the least universal SDK of them all.

    • Avatar

      ecumenical

      In reply to Bill_Russell:


      The fact that you can make an interface that works on multiple device types doesn't preclude you from making an interface that only works on one device type. Nobody holds a gun to a dev's head and says "THIS MUST WORK WITH TOUCH AND HOLOLENS AND XBOX." They're welcome to make a desktop-only app.

      • Avatar

        hrlngrv

        In reply to ecumenical:

        Software benefiting from more control-dense UIs would tend to be desktop applications. Perhaps there's a market for Windows-only desktop software, which is what UWP-based desktop software would be. Adobe may not even what to do that since it'd mean Mac versions would be quite different from Windows UWP versions.

        The screen shot above looks somewhat like R Studio, but R Studio runs under Windows, macOS, and Linux. It uses QT, which provides scaling support for high resolution monitors, plus it makes it easier to use as close to a common source code base as may be possible for developers who want to support more than Windows.

        So the question may be how many developers of presumably complex desktop software which would benefit from control-dense UIs would want to develop such software exclusively for Windows using UWP?

        • Avatar

          ecumenical

          In reply to hrlngrv:


          "So the question may be how many developers of presumably complex desktop software which would benefit from control-dense UIs would want to develop such software exclusively for Windows using UWP?"


          Probably none or effectively none. What does that have to do with the original post erroneously claiming that all UWP apps have to have touch-optimized interfaces?

          • Avatar

            skane2600

            In reply to ecumenical:

            Whether it achieves it or not UWP was obviously planned to allow a class of apps to run on multiple Windows platforms and the emphasis was on mobile with touch being a very important part of the initiative.


            So while a developer can certainly ignore all of that, it's not really unreasonable for someone to observe that a particular application or library is in opposition to the intent of UWP.

      • Avatar

        skane2600

        In reply to ecumenical:

        If you're solely targeting Windows. a traditional desktop program allows more design approaches and can take advantage of Win32's greater power. So the question is why bother with UWP?

        • Avatar

          hrlngrv

          In reply to skane2600:

          Well this forum post seems to indicate that some people believe there's money to be made from supporting UWP development. Do we or don't we have a moral obligation to crap all over that fantasy?

        • Avatar

          ecumenical

          In reply to skane2600:


          I'm not advocating that a developer use UWP. I'm responding the statement that " you need to have the fat fingered touchscreen user in mind." This is obviously wrong, since you can make a command-dense UI in UWP that is as good as anything done in WinForms or WPF.


          On the other hand, using WinForms or WPF to make a HoloLens, Xbox, or touch-optimized app would be impossible or a nightmare. But those are all niche use cases that have far too little weight to drive people toward UWP development in general.

  8. Avatar

    hrlngrv

    Are there any actual UWP apps using this?

    Until there are, consider that mainstream UWP developer may be an oxymoron.

  9. Avatar

    ecumenical

    The problem was never that mainstream UWP developers were blocked from creating high-density interfaces by the platform itself. As you note, this claim was always essentially BS and I've never figured out why Paul, who claims to be at least somewhat familiar with development, keeps repeating it. If the buttons are too big, go into myButton.width and make it smaller...


    The more significant problem, though, is one that Paul's exactly right about. There are no mainstream UWP developers, and so there's nobody with skill taking the platform and using it to create high-quality, useful apps. The store is getting a little better between games, iTunes, Affinity Designer/Photo, Paint.NET and a few others, but none of that is being driven by UWP development.

    • Avatar

      skane2600

      In reply to ecumenical:

      Most individual developers can't make a living writing apps on any platform, so it's really employers that make or break a platform. There aren't many UWP developers because there aren't many companies hiring them. Windows phone never reached a minimum level of market share to support development and UWP on the desktop was mostly just a redundant subset of what was already available via Win32. So, for the most part there was no business case for third-party UWP development.

  10. Avatar

    lordbaal1

    Some tomatoes, lettuce, cheese and bacon, would go good with this spam.

  11. Avatar

    Tony Barrett

    UWP is functionally limited - by design. It has to be cross platform, cross architecture, portable and secure, so something had to give. UWP apps are generally restricted in capability, and even Microsoft's own tier 1 UWP apps have been embarrassingly bad. If they can't get it right, nobody can.

    Win32 will aways be a more flexible dev platform, but it's designed mainly for point and click, which naturally leads to a more dense, finer grained UI, which it seems, the majority prefer. UWP was primarily designed for touch on small screen devices, something that now isn't an option for MS, meaning UWP also doesn't have it's original design platform available.

    • Avatar

      klients

      In reply to ghostrider:

      Can you give some technical examples where "UWP apps are restricted in capability"?


      As a software developer for 15 years, I'm not aware of any meaningful example of that.

      • Avatar

        skane2600

        In reply to klients:

        Can UWP apps provide the ability to be automated from the outside similar to what one can do with vbscript and Office?

        • Avatar

          klients

          In reply to skane2600:


          I just replied to this above. Short answer: Yes, it is possible.

          • Avatar

            skane2600

            In reply to klients:

            I'm not talking about GUI automation, BTW as someone who has extensive experience in using such systems I can tell you the script you write is very fragile and can stop working if the application you automate is updated in a way that changes the UI elements.


            I'm talking abut automation at a deeper level with something like:


            set obj = CreateObject("Word.Application")

            obj.Application.Documents.Open(aFile.Path)


            etc

            • Avatar

              klients

              In reply to skane2600:


              I'm not familiar with this scenario, but it seems possible with UWP app services:

              docs.microsoft.com/en-us/windows/uwp/launch-resume/how-to-create-and-consume-an-app-service


              The example on that article is for a UI-less scenario, but you could also hook it to the UI if needed.


              Edit: App services is for "scripts" that run outside the app.

              If the script must run inside the app, then we can use a different approach. For example: blogs.u2u.be/diederik/post/Extend-your-UWP-apps-with-Lua-scripting

              • Avatar

                skane2600

                In reply to klients:

                That doesn't really appear to be equivalent and the app service description makes it fairly clear that a UI isn't supported. That would be consistent with Windows services in general.


                But it's not really about a service offering a small set of functionality to apps, but rather a standard way to automate a full app (provided that the app conforms to the standard).

                • Avatar

                  klients

                  In reply to skane2600:


                  There is another article on running app services in-process. From there, it is trivial to invoke the UI.


                  I don't understand what you mean by "a standard way". vbscript is not a "standard" way to automate Win32 apps.


                  Ultimately, it is possible to automate a UWP app. So, that should cover your question.

                • Avatar

                  skane2600

                  In reply to klients:

                  Isn't an app service (in-process or out of process) the "server" and the code that invokes it, the client? Services don't usually invoke the client. What is the mechanism by which the UI code makes an interface available to the service?


                  While vbscript isn't "the" standard way of automating Win32 apps, it is one of the standard ways of automating Win32 apps. At the core, it's all about the Component Object Model.

  12. Avatar

    Daishi

    I guess it depends how closely you want to stick to Microsoft's design guidelines. If you are prepared to throw them to the wind then sure, you can do almost anything really. I'm not sure it's going to find its way into the store though and I think that's more the point than the technical capabilities of the platform.

  13. Avatar

    klients

    NOTE: The point of this thread is the technical capabilities of the UWP platform.


    Let's leave the success/failure of UWP apps/developers to a different conversation.


    Does everyone agree that, technically, the UWP platform is quite capable? If not, what feature is missing?

  14. Avatar

    tompkin

    As I remember, UWP was originally supposed to be used for Windows Phone, Tablet, and Desktop. Since that time a number of things happened. Windows Phone failed. Now, Microsoft (rightfully so) is focusing on putting their mobile apps on iPhone and Android. Also, Windows 10 has taken a "supporting role" in their Enterprise focus. The success of UWP may depend on if Microsoft can convince their Enterprise customers to accept it.


    Most people like what they know. I personally still like the Outlook 2016 version better than the Outlook app. When I use the Outlook app it seems that it's not as mature as Outlook 2016. And I don't think it is. In order for me to use the Outlook app it would have to give me a reason to do so and right now I don't see it.


    But I don't really think that the future of UWP will depend upon me, the regular user, so much as the Enterprise acceptance.

Leave a Reply