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

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.

Conversation 70 comments

  • safrane

    08 May, 2018 - 3:08 pm

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

  • Daekar

    08 May, 2018 - 3:14 pm

    <p>Sure looks like a useful UI to me…</p>

  • lordbaal1

    08 May, 2018 - 4:35 pm

    <p>Some tomatoes, lettuce, cheese and bacon, would go good with this spam.</p>

  • ecumenical

    08 May, 2018 - 4:52 pm

    <p>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…</p><p><br></p><p>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. </p>

    • skane2600

      09 May, 2018 - 1:50 am

      <blockquote><a href="#273351"><em>In reply to ecumenical:</em></a></blockquote><p>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. </p>

  • hrlngrv

    Premium Member
    08 May, 2018 - 5:05 pm

    <p>Are there any actual UWP apps using this?</p><p>Until there are, consider that <em>mainstream UWP developer</em> may be an oxymoron.</p>

    • Paul Thurrott

      Premium Member
      11 May, 2018 - 8:53 am

      <blockquote><a href="#273357"><em>In reply to hrlngrv:</em></a></blockquote><p>Exactly.</p>

  • Bill Russell

    08 May, 2018 - 5:28 pm

    <p>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. </p>

    • ecumenical

      08 May, 2018 - 8:02 pm

      <blockquote><a href="#273371"><em>In reply to Bill_Russell:</em></a></blockquote><p><br></p><p>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.</p>

      • hrlngrv

        Premium Member
        08 May, 2018 - 9:21 pm

        <p><a href="#273412"><em>In reply to ecumenical:</em></a></p><p>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.</p><p>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.</p><p>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?</p>

        • ecumenical

          09 May, 2018 - 1:30 am

          <blockquote><a href="#273417"><em>In reply to hrlngrv:</em></a></blockquote><p><br></p><p>"<span style="color: rgb(0, 0, 0); background-color: transparent;">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?"</span></p><p><br></p><p><span style="color: rgb(0, 0, 0); background-color: transparent;">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?</span></p>

          • skane2600

            09 May, 2018 - 1:41 am

            <blockquote><a href="#273492"><em>In reply to ecumenical:</em></a></blockquote><p>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. </p><p><br></p><p>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.</p>

      • skane2600

        08 May, 2018 - 11:16 pm

        <blockquote><a href="#273412"><em>In reply to ecumenical:</em></a></blockquote><p>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? </p>

        • hrlngrv

          Premium Member
          09 May, 2018 - 1:11 am

          <p><a href="#273444"><em>In reply to skane2600:</em></a></p><p>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?</p>

          • skane2600

            09 May, 2018 - 1:54 am

            <blockquote><a href="#273490"><em>In reply to hrlngrv:</em></a></blockquote><p>I don't see any moral obligation either way. If people can find a way of to make money by supporting UWP, that's great. </p>

          • Chris_Kez

            Premium Member
            09 May, 2018 - 9:42 am

            <blockquote><a href="#273490"><em>In reply to hrlngrv:</em></a></blockquote><p>"Do we or don't we have a moral obligation to crap all over that fantasy?"</p><p>Given the choice between having someone take a steaming dump on their fantasy, or having someone provide a constructive, objective correction, I think most people would prefer the latter. ;)</p>

            • lvthunder

              Premium Member
              09 May, 2018 - 11:06 am

              <blockquote><a href="#273702"><em>In reply to Chris_Kez:</em></a></blockquote><p>I think you are wrong. People enjoy dumping on other people instead of having a constructive informed discussion.</p>

          • Sprtfan

            09 May, 2018 - 10:01 am

            <blockquote><a href="#273490"><em>In reply to hrlngrv:</em></a></blockquote><p>The thread is only saying that a h<span style="background-color: rgb(255, 255, 255);">igh density UI is possible which goes against what Paul has been saying. I don't see any mention of making money. </span></p>

            • hrlngrv

              Premium Member
              09 May, 2018 - 2:05 pm

              <p><a href="#273709"><em>In reply to Sprtfan:</em></a></p><p>Fine. The screen shot doesn't show anything like a toolbar with just icons. Most of the dense UIs I've used employ toolbars. Are user-customizable toolbars possible in UWP? Are ribbon UIs possible with UWP? And for those who automate some interactive tasks, can any UWP software be automated with 3rd party macro tools like AutoIt by simulating keystrokes, mouse movements and mouse button presses?</p>

        • ecumenical

          09 May, 2018 - 1:36 am

          <blockquote><a href="#273444"><em>In reply to skane2600:</em></a></blockquote><p><br></p><p>I'm not advocating that a developer use UWP. I'm responding the statement that "<span style="color: rgb(0, 0, 0); background-color: transparent;"> you need to have the fat fingered touchscreen user in mind." This is obviously wrong, since you can make </span>a command-dense UI in UWP that is as good as anything done in WinForms or WPF. </p><p><br></p><p>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.</p>

  • klients

    08 May, 2018 - 6:56 pm

    <p>NOTE: The point of this thread is the <em>technical capabilities of the UWP platform</em>.</p><p><br></p><p>Let's leave the success/failure of UWP apps/developers to a different conversation.</p><p><br></p><p>Does everyone agree that, technically, the UWP platform is quite capable? If not, what feature is missing?</p>

    • hrlngrv

      Premium Member
      09 May, 2018 - 1:09 am

      <p><a href="#273399"><em>In reply to klients:</em></a></p><p>Is there any value in discussing the technical capabilities of a development platform few are using? Technically, assembly language is quite capable, and everything which runs on PCs could be implemented in assembly language. Yet it's not much used for Windows application development. How odd.</p>

      • Chris_Kez

        Premium Member
        09 May, 2018 - 9:06 am

        <blockquote><a href="#273489"><em>In reply to hrlngrv:</em></a></blockquote><p>Will further clarification of UWP's technical capabilities have a huge impact? Probably not, but it doesn't hurt either. My sympathies lie with anyone who wants to make people more informed. </p>

      • klients

        09 May, 2018 - 9:20 am

        <blockquote><a href="#273489"><em>In reply to hrlngrv:</em></a></blockquote><p>Paul was questioning its technical capabilities, hence this thread.</p>

  • Daishi

    Premium Member
    08 May, 2018 - 7:49 pm

    <p>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.</p>

    • ecumenical

      08 May, 2018 - 8:00 pm

      <blockquote><a href="#273409"><em>In reply to Daishi:</em></a></blockquote><p><br></p><p>Are you suggesting that Microsoft enforces its design guidelines on store apps? If so, LOL and also go check out the store sometime. </p>

    • Daekar

      09 May, 2018 - 11:16 am

      <blockquote><a href="#273409"><em>In reply to Daishi:</em></a></blockquote><p>Gauss Rifles or PPCs?</p>

      • Daishi

        Premium Member
        09 May, 2018 - 6:35 pm

        <blockquote><em><a href="#273720">In reply to Daekar:</a></em></blockquote><p>PPCs every time. </p>

  • Tony Barrett

    09 May, 2018 - 9:57 am

    <p>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. </p><p>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.</p>

    • klients

      09 May, 2018 - 2:48 pm

      <blockquote><a href="#273707"><em>In reply to ghostrider:</em></a></blockquote><p>Can you give some technical examples where "UWP apps are restricted in capability"?</p><p><br></p><p>As a software developer for 15 years, I'm not aware of any meaningful example of that.</p>

      • skane2600

        09 May, 2018 - 3:24 pm

        <blockquote><a href="#273796"><em>In reply to klients:</em></a></blockquote><p>Can UWP apps provide the ability to be automated from the outside similar to what one can do with vbscript and Office? </p>

        • klients

          09 May, 2018 - 3:30 pm

          <blockquote><a href="#273814"><em>In reply to skane2600:</em></a></blockquote><p><br></p><p>I just replied to this above. Short answer: Yes, it is possible.</p>

          • skane2600

            09 May, 2018 - 4:42 pm

            <blockquote><a href="#273822"><em>In reply to klients:</em></a></blockquote><p>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.</p><p><br></p><p>I'm talking abut automation at a deeper level with something like:</p><p><br></p><p>set obj = CreateObject("Word.Application")</p><p>obj.Application.Documents.Open(aFile.Path)</p><p><br></p><p>etc</p>

            • klients

              09 May, 2018 - 5:11 pm

              <blockquote><a href="#273879"><em>In reply to skane2600:</em></a></blockquote><p><br></p><p>I'm not familiar with this scenario, but it seems possible with UWP app services:</p><p>docs.microsoft.com/en-us/windows/uwp/launch-resume/how-to-create-and-consume-an-app-service</p><p><br></p><p>The example on that article is for a UI-less scenario, but you could also hook it to the UI if needed.</p><p><br></p><p>Edit: App services is for "scripts" that run outside the app.</p><p>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</p>

              • skane2600

                09 May, 2018 - 6:01 pm

                <blockquote><a href="#273907"><em>In reply to klients:</em></a></blockquote><p>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.</p><p><br></p><p>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).</p>

                • klients

                  09 May, 2018 - 6:22 pm

                  <blockquote><a href="#273942"><em>In reply to skane2600:</em></a></blockquote><p><br></p><p>There is another article on running app services in-process. From there, it is trivial to invoke the UI.</p><p><br></p><p>I don't understand what you mean by "a standard way". vbscript is not a "standard" way to automate Win32 apps.</p><p><br></p><p>Ultimately, it is possible to automate a UWP app. So, that should cover your question.</p>

                • skane2600

                  09 May, 2018 - 6:48 pm

                  <blockquote><a href="#273948"><em>In reply to klients:</em></a></blockquote><p>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? </p><p><br></p><p>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.</p>

  • klients

    09 May, 2018 - 3:27 pm

    <p> To answer hrlngrv&nbsp;(for some reason, I can't post this as a reply):</p><p><br></p><p>Yes, it is technically possible to create user-customizable toolbars in UWP.</p><p>Here is a simple example: http://www.actiprosoftware.com/Content/Images/platforms/controls-universal/gallery/SyntaxEditorSDIEditor.png</p><p>The Ribbon is just more of the same.</p><p><br></p><p>AutoIt doesn't support .NET apps (incl WPF). They explicitly choose to not support them: http://www.autoitscript.com/forum/topic/80556-autoit-support-for-wpf-and-net-35-applications/?do=findComment&amp;comment=673920</p><p><br></p><p>But there are other automation tools like pywinauto that do: github.com/pywinauto/pywinauto</p><p><br></p>

    • hrlngrv

      Premium Member
      09 May, 2018 - 3:51 pm

      <p><a href="#273819"><em>In reply to klients:</em></a></p><p>Point remains: how much market is there for complex software which would only run under Windows 10?</p><p>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.</p><p>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, <strong>not even MSFT itself</strong>, are using them, what does it matter?</p>

      • klients

        09 May, 2018 - 3:56 pm

        <blockquote><a href="#273838"><em>In reply to hrlngrv:</em></a></blockquote><p><br></p><p>Like I said, the discussion here is not how successful UWP is as a business.</p><p><br></p><p>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.</p>

        • klients

          09 May, 2018 - 5:56 pm

          <blockquote><a href="#273923"><em>In reply to hrlngrv:</em></a></blockquote><p><br></p><p>Here is the most recent comment from Paul (written a few hours ago):</p><p><em>"I have been complaining about UWP UI density (which I called command density) for years…"</em></p><p>twitter.com/thurrott/status/993885560665092096</p><p><br></p><p>And I want to stay away from unsubstantiated claims/speculations.</p><p>If we can't come up with an actual example of a limitation, then we can move the UWP conversation forward.</p>

          • hrlngrv

            Premium Member
            09 May, 2018 - 8:08 pm

            <p><a href="#273941"><em>In reply to klients:</em></a></p><blockquote>. . . If we can't come up with an actual example of a limitation, then we can move the UWP conversation forward.</blockquote><p>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 <strong><em>better</em></strong> than older, established approaches to gain appreciable uptake. Is UWP better?</p><p>BTW, I don't use Twitter, so I have no idea what Paul Thurrott tweats.</p>

  • jimchamplin

    Premium Member
    09 May, 2018 - 10:48 pm

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

  • Paul Thurrott

    Premium Member
    10 May, 2018 - 10:04 am

    <p>This is a third party solution. Microsoft literally just announced "UI density" capabilities for UWP this week at Build.</p><p><br></p><p>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.</p><p><br></p><p><br></p>

    • lvthunder

      Premium Member
      10 May, 2018 - 11:13 am

      <blockquote><a href="#274170"><em>In reply to paul-thurrott:</em></a></blockquote><p>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.</p><p><br></p><p>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.</p>

      • Paul Thurrott

        Premium Member
        10 May, 2018 - 11:48 am

        <blockquote><a href="#274200"><em>In reply to lvthunder:</em></a></blockquote><p>How would I know … what?</p>

        • lvthunder

          Premium Member
          11 May, 2018 - 12:01 pm

          <blockquote><a href="#274213"><em>In reply to paul-thurrott:</em></a></blockquote><p>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.</p>

          • skane2600

            11 May, 2018 - 12:29 pm

            <blockquote><a href="#274567"><em>In reply to lvthunder:</em></a></blockquote><p>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.</p>

            • hrlngrv

              Premium Member
              11 May, 2018 - 2:51 pm

              <p><a href="#274572"><em>In reply to skane2600:</em></a></p><blockquote>. . . many ideas developed over years from Microsoft Office . . .</blockquote><p>Those ideas didn't spring newborn from the minds of MSFT developers.</p><p>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?).</p>

              • skane2600

                11 May, 2018 - 3:50 pm

                <blockquote><a href="#274610"><em>In reply to hrlngrv:</em></a></blockquote><p>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. </p><p><br></p><p>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).</p><p><br></p><p><br></p>

                • hrlngrv

                  Premium Member
                  11 May, 2018 - 11:15 pm

                  <blockquote><a href="#274632"><em>In reply to skane2600:</em></a></blockquote><p>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).</p>

                • skane2600

                  12 May, 2018 - 1:14 am

                  <blockquote><a href="#274682"><em>In reply to hrlngrv:</em></a></blockquote><p>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.</p><p><br></p><p>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,</p>

                • hrlngrv

                  Premium Member
                  13 May, 2018 - 8:44 pm

                  <blockquote><a href="#274688"><em>In reply to skane2600:</em></a></blockquote><p>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.</p>

                • skane2600

                  13 May, 2018 - 10:47 pm

                  <blockquote><a href="#275143"><em>In reply to hrlngrv:</em></a></blockquote><p>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.</p><p><br></p><p>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.</p><p><br></p><p>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.</p>

          • hrlngrv

            Premium Member
            11 May, 2018 - 2:45 pm

            <p><a href="#274567"><em>In reply to lvthunder:</em></a></p><blockquote>. . . no one would care that much . . .</blockquote><p>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.</p><p>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?</p><p>I'll repeat something I've already written: <strong><em>new</em></strong> usually has to be better than <strong><em>old</em></strong> to have a chance of supplanting <strong><em>old</em></strong>. Is UWP sufficiently <strong><em>better</em></strong> than Win32 at complex, control-dense UIs?</p>

      • hrlngrv

        Premium Member
        10 May, 2018 - 2:29 pm

        <p><a href="#274200"><em>In reply to lvthunder:</em></a></p><p>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.</p>

      • skane2600

        10 May, 2018 - 5:14 pm

        <blockquote><a href="#274200"><em>In reply to lvthunder:</em></a></blockquote><p>"There is no difference in a UWP, PWA, or Bridge app in the store."</p><p><br></p><p>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. </p><p><br></p><p><br></p><p>"Also when was the last time a high profile, professional-looking (Office or Photoshop) app was started from scratch."</p><p><br></p><p>Well, when was the last time this occurred on ANY platform? In any case, if new "high profile, professional-looking"&nbsp;programs are no longer being created, that really has nothing to do with relative desirability of developing for UWP.</p><p><br></p><p>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.</p><p><br></p><p><br></p>

        • klients

          10 May, 2018 - 5:41 pm

          <blockquote><a href="#274377"><em>In reply to skane2600:</em></a></blockquote><p><br></p><p>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.</p>

          • skane2600

            10 May, 2018 - 6:02 pm

            <blockquote><a href="#274390"><em>In reply to klients:</em></a></blockquote><p>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". </p><p><br></p><p>It's just that UWP's "out of the box" UI support is more focused on touch based UI elements than traditional Windows elements. </p>

            • klients

              11 May, 2018 - 1:14 am

              <blockquote><a href="#274402"><em>In reply to skane2600:</em></a></blockquote><p><br></p><p>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.</p>

              • skane2600

                11 May, 2018 - 11:32 am

                <blockquote><a href="#274496"><em>In reply to klients:</em></a></blockquote><p>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.</p>

              • hrlngrv

                Premium Member
                11 May, 2018 - 2:33 pm

                <p><a href="#274496"><em>In reply to klients:</em></a></p><blockquote>. . . dev team is working on a "high density" app . . .</blockquote><p>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.</p><p>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.</p><p>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 &amp; truly be dead whatever its capabilities.</p>

    • klients

      10 May, 2018 - 2:03 pm

      <blockquote><a href="#274170"><em>In reply to paul-thurrott:</em></a></blockquote><p><br></p><p>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.</p><p><br></p><p>To reply to your specific comment:</p><p>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.)</p><p><br></p><p>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.</p><p>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.</p><p>These are great time-savers for developers.</p>

      • Paul Thurrott

        Premium Member
        11 May, 2018 - 8:53 am

        <blockquote><a href="#274273"><em>In reply to klients:</em></a></blockquote><p>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.</p><p>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.</p><p>I don't quite get the aggression or enmity here.</p>

        • klients

          11 May, 2018 - 10:22 am

          <blockquote><a href="#274534"><em>In reply to paul-thurrott:</em></a></blockquote><p><br></p><p>The most time-consuming and costly part of complex apps is not the UI, it is the business logic behind it.</p><p><br></p><p>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.</p><p><br></p><p>Devs build (complex) apps as a business, so I would look first for what would make sense business-wise before blaming the technology.</p><p><br></p><p>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.</p><p><br></p><p>Finally, I hope I wasn't being aggressive. I appreciate having deep factual conversations.</p>

          • hrlngrv

            Premium Member
            11 May, 2018 - 2:36 pm

            <p><a href="#274547"><em>In reply to klients:</em></a></p><blockquote>The most time-consuming and costly part of complex apps is not the UI, it is the business logic behind it. . . .</blockquote><p>You mean <strong><em>new</em></strong> 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?</p><p>If you mean porting existing software, the desktop bridge would be a far more economical alternative. Also, the <em>business logic</em> is already well known, and if it takes considerable effort to port it from Win32 to UWP, UWP is again dead because uneconomical.</p>

          • jimchamplin

            Premium Member
            11 May, 2018 - 11:24 pm

            <blockquote><a href="#274547"><em>In reply to klients:</em></a></blockquote><p>"The most time-consuming and costly part of complex apps is not the UI, it is the business logic behind it."</p><p><br></p><p>– Anyone who thinks UI doesn't matter</p><p><br></p><p>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.</p>

        • skane2600

          11 May, 2018 - 11:43 am

          <blockquote><a href="#274534"><em>In reply to paul-thurrott:</em></a></blockquote><p>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.</p><p><br></p><p>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?</p><p><br></p><p> </p>

  • doofus2

    11 May, 2018 - 1:55 am

    <p>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? </p>

  • tompkin

    12 May, 2018 - 7:16 am

    <p>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. </p><p><br></p><p>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.</p><p><br></p><p>But I don't really think that the future of UWP will depend upon me, the regular user, so much as the Enterprise acceptance. </p>

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC