On Sunday, 21 June 2015 at 06:20:53 UTC, Ola Fosheim Grøstad wrote:
> Thrown away in favour of what?

As I said before, start from scratch.  Stop trying to shoehorn a full app runtime into the browser because you will only lose to native app runtimes, which is already happening because they aren't constrained by such legacy decisions as an archaic document format.

If you want to build an app runtime that has hyperlinks built in, like the web does, start from a clean sheet and really think about how you want to do it.  Simply dumping more features on top of the old web stack is a recipe for failure.

> You need a scene-graph / DOM.

Not really, certainly not the latter if you chuck HTML/CSS/JS.

> CSS makes design much easier than the alternative.

Only if the alternative is web design circa 1995.  Once you chuck HTML, CSS has no reason to stick around.

> JS is evolving into something close to TypeScript.

You've got to be joking: why would anyone want to use either?  On the server, where you could use anything you want and there is real competition, almost nobody uses either, node.js in recent years and that's about it.  If this webasm effort ever got into most browsers, I guarantee that almost everybody would chuck javascript and compile java, C#, or D to the browser instead.

>> You can do some interesting things with caching, sure, but the web frontend is still unwieldy and slow and round-trip latency anytime you do something is what kills you.
>
> You can prefetch data if you want. If you have a scrolling view you can prefetch the next page-height worth of items. I do that for images where I have to deal with thousands of images.

Prefetching and caching is used by _all_ app runtimes, whether Java or Objective-C.  They don't change the fact that the web frontend is much slower and difficult to work with.

>> document format.  You are always going to be constrained by the architectural constraints and inefficiency of the document format.
>
> You don't have to use it. I use it because it is more productive and more easily allows search engine indexing.

Actually, that's one of the big problems with the more dynamic model: it breaks search engine indexing.  How does the crawler have any idea how to navigate an app UI and generate URLs that are meaningful, if they're even made available by the app?

> If you don't want it, you can use the HTML5 canvas and fill the view with it. But why would you? You would have to do all the layout manually and create a separate version for people using assistive technologies.

The HTML5 canvas does provide a way out to some extent, but you're still stuck with javascript and I believe a certain amount of CSS.  You wouldn't do the layout manually, just download a javascript library that does a lot of the grunt work for you.  It is on the right track, but goes nowhere near far enough.  But as I noted earlier, the canvas tag doesn't even support hyperlinks natively, which is a pretty big omission for a web technology.

>>> You can do that if you want. Just download binary data and plot it to a canvas.
>>
>> The fact that I could render SVG images to a png and download that instead doesn't excuse the fact that they're putting full text SVG renderers into the browser.
>
> You can just send paths as binary data to the client and draw to HTML5 canvas if you want. No need to render on the server.

Simply repeating a point, which I already addressed and noted was irrelevant, doesn't add anything to the discussion.

> Of course, that also means that you have to deal with resolution/zooming issues, and it also means that you may have to wait with the graphics till the whole DOM has loaded. Which is another issue that embedded SVG solves.

So your point is that your suggested binary fallback doesn't quite work as advertised to replace SVG?  Never heard of anyone suggesting an alternative, then pointing out it doesn't actually work. As I already noted, SVG doesn't have to be text to be "embedded."

> I wouldn't mind an improved version of SVG with LOD support etc, but I think that would be a different concept. SVG is perfectly fine for embedded CSS styled line-art (which I use it for). You can bundle HTML/CSS/JS/SVG in one file and have very responsive websites if you wish (one file download).

Very responsive because they're made up of trivially simple line art, perhaps.

>> Of course you could use binary SVG dynamically: you'd simply need the right hooks in the browser and in the binary format to manipulate it using javascript.  It would not require "binary-format editors" or "binary HTML."
>
> No, because I typically write the fragments for the SVG as text then programatically modify parts of the SVG. Or, I just attach event-listeners to parts of the SVG. Not having HTML and SVG in the same source would be very confusing.

It wouldn't be confusing at all.  You'd simply do all that in your text SVG authoring format and HTML on your side, then compile SVG to a binary encoding on the server and send that to the browser.  The browser would have to understand this binary encoding instead of text SVG and do all the same steps it does with text SVG now, except it would all work much faster for the user. :)

On Sunday, 21 June 2015 at 07:38:02 UTC, Nick Sabalausky wrote:
> On 06/21/2015 01:42 AM, Joakim wrote:
>> At this point, it's just a software issue.  Mobile devices just need UI
>> features like multiwindow to make more capable use of large desktop
>> monitors.
>>
>
> No, there's more to a desktop/laptop than just processing power and keyboard/monitor/mouse. The mobile devices are also (currently) shit at storage space (not to mention virtual memory) and peripherals. And then for devs, ie the people who actually make all this stuff in the first place, there's even more improvements needed.

I have almost 50 GBs of storage on my tablet, between the built-in flash and an SD card, about half what I have on my ultrabook.  If I weren't filling that 50 GBs up with many GBs of HD video, that's plenty of space for most people.  As for peripherals, you're talking printers and scanners?  Do people even use those anymore? :) If there's any demand for those at all, the dock for your smartphone will have a USB hub that supports them.

As for devs, they're a small percentage of the computer-using public, similar to hard-core gamers who want the most expensive graphics cards.  But even devs, most of whom certainly aren't using massive rigs with Xeons and 32 GBs of RAM, will make the switch.  The biggest issue there is the x86-centric toolchains most are using, but those should transition to ARM fairly quickly.

> I'm not saying it can't or won't reach parity with traditional laptop/desktop. The groundwork is there and it IS now feasible at least. But there's still a lot left. And, to even get there at all, the mobile OS/device devs will have to accept that it will require adopting more and more desktop/laptop features.

Not much left if you ask me, just multiwindow UIs, which could have been done at least a year earlier, and transitioning the few remaining desktop apps that haven't made the mobile transition yet.

> And I think that's the biggest question mark, as they seem quite loathe to accept that mobile-style (or really, iOS-style, which everyone else in mobile copied wholesale) isn't universally superior for everyone in every way. This attitude will prevent them from reaching parity and replacing desktops/laptops until for as long as they choose to cling to it. How long they'll cling to it is the question.

"mobile-style" is a very vague term, presumably you're referring to the prevailing mobile touch GUIs.  As I pointed out, the UI will need to be adapted for desktop monitors.

> But suppose, sooner or later, they've finally managed to improve enough to render the traditional line of desktops/laptops obsolete. It *WON'T* be a case of "mobile killed desktop". Because they will have, by necessity, BECOME just as much desktop as smartphone - the only difference being the lineage. It would be, in effect, exactly the same as laptops gaining mobile capabilities and mobile-friendly UI. Except, oh wait, that's happening too, see MS Surface Pro.

That's what I detailed below: it's not the same and the failure of Surface and other Windows two-in-ones shows that.

> So it's NOT mobile replacing desktop/laptop. It's not "the new defeating the old" as the smartphone/tablet fans would have everyone believe. It's just plain old convergence. Neither side will "win" over the other because winning this game requires erasing the lines between both sides.

It _is_ convergence of software UIs, but it is killing off of the old hardware form factors and previous underlying desktop operating systems.

>> Yes and no.  As hardware form factors, the old desktop and laptop models
>> are being ditched.  The desktop box will almost completely disappear,
>> while the folding laptop is only really needed by a small niche, those
>> for whom "lap-ability" in a plane or conference seat is needed.  I
>> picked up a bluetooth keyboard for my tablet last year: that suffices
>> for me, and I bet most people, since I'm always going to put them down
>> on a hard surface before typing.  I bet 97% of the people who currently
>> use laptops are in this category.
>
> And then you need some place to set the phone/tablet. The natural choice is to dock it into the keyboard, ideally with some sort of hinge. At which point you've just re-invented the laptop form factor.

I disagree that the keyboard is the natural place to dock the phone/tablet, and the failure of such devices, both on the Android side and especially on the Windows side, seems to show this.  I simply prop up my tablet on my desk on the side of something, whereas most will likely just dock them in small holders, either just to hold them up or to provide ports to connect to a larger monitor.

> The usefulness of laptop form factor won't go away, People will just start failing to recognize that it's just a laptop in new clothes with a few more tricks.

It will go away, for the reasons I've given.  Does that mean nobody will use laptops?  Of course not, people still use mainframes and giant workstations.  You just never see them around anymore, because it's such a small niche. :)

>> As for the desktop OS, Windows has essentially no penetration on mobile,
>> while OS X and linux live on only in the core kernels of their mobile
>> counterparts.
>>
>> All that is converging is the software UIs, where mobile devices will be
>> able to display apps appropriately both for constrained touchscreens and
>> larger monitors controlled by a keyboard/trackpad.  Only in that last
>> sense are mobile devices converging, by adding software UIs to work on
>> large screens.
>>
>
> No, as you already pointed out yourself, the hardware capabilities are converging as well.

Heh, never said anything of the sort.  Anyway, it's funny that you respond to a quote limited to software and UIs by going on about hardware again, never mentioning software. :)

> And then you have on one hand the whole "hooking up a keyboard/mouse" to a phone/tablet (and monitor too, HDMI-out has become pretty common on Android)...

What is your point, that because we're still using keyboards and mice, they're "converged?"  A car still moves on wheels yet nobody would say it "converged" with a horse and carriage.  One feature, the wheels, carried over, but most of it is completely different.  I think that since the underlying device, a smartphone, is fairly different from a mainframe or a PC, it's far-fetched to say the devices are "hybrid" or "converged," simply because they're all using similar input peripherals when used at a desk.

But even that is only temporary, as voice and gesture recognition will soon kill off those input peripherals too. :)

> And on the other hand, you have laptops getting their mainboards moved to the upper-half and becoming detachable from the bottom half, and getting smaller, lighter, better battery life...
>
> That...is form-factor convergence.

That might be actual hardware form-factor convergence, if anybody were buying those two-in-ones, but almost nobody is.

>>> Of course, that's dependent on the phone/tablet folks actually
>>> managing to pull it off. Which is certainly a possibility, I agree,
>>> but I'm not convinced they'll necessarily manage to, at least not in
>>> the short term.
>>
>> It's around the bend and frankly should have been done sooner.
>>
>
> Never underestimate the power of corporate ineptitude ;)

I agree with the sentiment, just not sure what you're trying to indicate with the "corporate" qualifier.  "Ineptitude" alone would have sufficed. :)

On Sunday, 21 June 2015 at 09:07:52 UTC, Joakim wrote:
> As I said before, start from scratch.  Stop trying to shoehorn a full app runtime into the browser because you will only lose to native app runtimes, which is already happening because they aren't constrained by such legacy decisions as an archaic document format.

Start from scratch, in what direction? You need a design that is generic enough, yet more productive than what exists. And then you need to wait 5 years for end users to install the viewers, before you can use it.

I don't see native apps winning over the browser based apps. Only in very limited domains, of daily use (like purchasing tickets), but for non-technical reasons.

And let's face it, many "native" apps are 50% browser based, just wrapped up in a shell. They use the HTML5 web-view. Because it is easier and performs well enough.

> think about how you want to do it.  Simply dumping more features on top of the old web stack is a recipe for failure.

I hear you saying it, but installed base is way too important a factor to be ignored. What you can do is changing the underlying engine, but keep the compatibility.

>> You need a scene-graph / DOM.
>
> Not really, certainly not the latter if you chuck HTML/CSS/JS.

DOM is a scene-graph.

> You've got to be joking: why would anyone want to use either?

Because it is backwards compatible.

> recent years and that's about it.  If this webasm effort ever got into most browsers, I guarantee that almost everybody would chuck javascript and compile java, C#, or D to the browser instead.

Java has been available for years, almost nobody used it. Flash was available for years and it was only used in limited domains. Active-X was available. PNACL is available. asm.js is available, and webasm doesn't offer much more than asm.js in the near future.

You can wish, but certainly not guarantee.

> Actually, that's one of the big problems with the more dynamic model: it breaks search engine indexing.  How does the crawler have any idea how to navigate an app UI and generate URLs that are meaningful, if they're even made available by the app?

Google provide ways to index dynamic apps, but it is more work. So it costs more in developer time.

> enough.  But as I noted earlier, the canvas tag doesn't even support hyperlinks natively, which is a pretty big omission for a web technology.

Not sure what you mean by that? You trigger on the click and load the target page? Or if you wish, you can overlay hyper-link rectangles on top of the canvas.

The current model is quite flexible, you can mix technologies. Perhaps too flexible.

> actually work. As I already noted, SVG doesn't have to be text to be "embedded."

It has to be part of the DOM. Parsing is not the main issue.

> Very responsive because they're made up of trivially simple line art, perhaps.

Trivial is relative. You can't have full-on photon-based simulation. You can have an advanced webGL shader if you want. As long as the renderer is the bottleneck you have to design for the renderer, no matter what kind of renderer you have. And you have many:

1. HTML5/CSS
2. HTML5/CSS GPU transforms
3. SVG
4. Canvas2D
5. WebGL.

That's five different rendering strategies with different performance characteristics and you have to design your graphics for each one of them.

>> attach event-listeners to parts of the SVG. Not having HTML and SVG in the same source would be very confusing.
>
> It wouldn't be confusing at all.  You'd simply do all that in your text SVG authoring format and HTML on your side, then compile SVG to a binary encoding on the server and send that to the browser.

That would just be a different encoding of HTML5, if parsing was a major bottleneck, that might be a point. But it would have to coexist with the textual version and developers would only upgrade if it solves a problem.

In the scripting API using text as values might be an issue, but that's a different topic.

On Saturday, 20 June 2015 at 19:00:08 UTC, Joakim wrote:
> Pretty soon it won't. :) There are an estimated 2.5 billion smartphone users:
>
> http://www.asymco.com/2014/04/07/postmodern-computing/
>
> The highest estimates of desktop and laptop users I've seen don't crack 2 billion.  That means desktops are already a minority platform.

Do you think it's wise to ignore 2 billion users? The size of the mobile market doesn't mean you can target it entirely. The article suggests currently we have era of services and services are clustered by culture, which means you can't target users outside of your cultural cluster, while desktop applications usually target entire desktop market without exceptions.

> All the major mobile vendors are working on multi-window implementations which will soon allow you to plug your mobile device into a dock that connects to a monitor/keyboard/trackpad on your desk and run your mobile apps in a similar way to the desktop: Apple's just-announced multi-window feature to go along with their coming iPad Pro, Google's in-development multi-window implementation that has been found in the Android M build, and Microsoft's recently announced Continuum for mobile devices, that lets you plug your Windows Phone into a monitor and use Office with a desktop UI.

Are you going to support windows phone?

> What this means is that people will soon be using their mobile devices for almost everything and desktop computers are effectively dead. :) Now, workstations were killed off by PCs and they still sell a couple million worldwide.  Similarly, there will always be a niche for PCs and mainframes.  It's just a small niche.

It will be desktop for all practical purposes, just more constrained in resources. Mobile platform will embrace two unrelated ecosystems, and you will still have to choose which ecosystem you target, and since desktop is a minority, why you would care about mobile desktop? It will be minority for all the same reasons that make desktop minority.

On Saturday, 20 June 2015 at 19:00:08 UTC, Joakim wrote:
> On Saturday, 20 June 2015 at 15:21:29 UTC, Kagamin wrote:
>> High DPI settings screw up native UI too if it's not pixel-precise, and ignoring user preferences is infraction, I'm afraid. And this is where web actually shines: it's designed to adapt gracefully to any user settings. Well, of course when site design strays from how web was designed to work, it runs into problems, that should be obvious.
>
> The highest-DPI devices I use nowadays are mobile devices and, in my experience, websites are the ones who most often get it wrong.

I mean only design possibility, which is not taken advantage of in modern web, unfortunately.

>  That's usually related to tiny text, but that affects the overall layout too.

Designers like their 5-pixel fonts and believe everybody will appreciate them. But I think pixel-oriented design is a flawed design choice for web, web wasn't designed to work that way.

On Sunday, 21 June 2015 at 10:07:05 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 21 June 2015 at 09:07:52 UTC, Joakim wrote:
>> As I said before, start from scratch.  Stop trying to shoehorn a full app runtime into the browser because you will only lose to native app runtimes, which is already happening because they aren't constrained by such legacy decisions as an archaic document format.
>
> Start from scratch, in what direction? You need a design that is generic enough, yet more productive than what exists.

I've sketched out one possibility in the past, with more details in subsequent comments in that thread:

http://forum.dlang.org/post/dqddjhccpmxhgcssqtol@forum.dlang.org

Surely you could think of other approaches that would ditch the current document format also?

> And then you need to wait 5 years for end users to install the viewers, before you can use it.

Not necessarily, you'd probably start by simply linking your app into the viewer, ie using it just like any other UI toolkit library, until it became popular enough that you could separate out the viewer as its own app.

> I don't see native apps winning over the browser based apps. Only in very limited domains, of daily use (like purchasing tickets), but for non-technical reasons.

I think you are complete ignoring the current mobile app wave then.  There are plenty of valid technical reasons why web-centric organizations like Facebook tried to use HTML5 for their initial mobile apps but then had to backtrack to native mobile apps.

> And let's face it, many "native" apps are 50% browser based, just wrapped up in a shell. They use the HTML5 web-view. Because it is easier and performs well enough.

More likely because they already built a simple webapp and don't want to duplicate effort.  These are the low-end apps that started on the web, whereas those that start on mobile now often don't even bother with a webapp.

>> think about how you want to do it.  Simply dumping more features on top of the old web stack is a recipe for failure.
>
> I hear you saying it, but installed base is way too important a factor to be ignored. What you can do is changing the underlying engine, but keep the compatibility.

Browser install base is overrated in this day and age when people install apps aplenty and easily from mobile app stores.  They've been trying to change the underlying engine for a couple decades now and haven't gotten very far.

>>> You need a scene-graph / DOM.
>>
>> Not really, certainly not the latter if you chuck HTML/CSS/JS.
>
> DOM is a scene-graph.

Which is why I said you could chuck the DOM, but probably want some simpler kind of scene graph instead.

>> You've got to be joking: why would anyone want to use either?
>
> Because it is backwards compatible.

You were arguing that it wasn't that bad.  If the only reason you can give is because it's legacy tech, you just argued against yourself. :)

>> recent years and that's about it.  If this webasm effort ever got into most browsers, I guarantee that almost everybody would chuck javascript and compile java, C#, or D to the browser instead.
>
> Java has been available for years, almost nobody used it. Flash was available for years and it was only used in limited domains. Active-X was available. PNACL is available. asm.js is available, and webasm doesn't offer much more than asm.js in the near future.
>
> You can wish, but certainly not guarantee.

You seem to have missed the discussion above.  I guessed that they were allowing webasm to directly manipulate the DOM, rather than having to ca

Hmm, looks like the rest of my response got lost on the way to the newsgroup somewhere, reposting the rest below:

On Sunday, 21 June 2015 at 10:07:05 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 21 June 2015 at 09:07:52 UTC, Joakim wrote:
>> recent years and that's about it.  If this webasm effort ever got into most browsers, I guarantee that almost everybody would chuck javascript and compile java, C#, or D to the browser instead.
>
> Java has been available for years, almost nobody used it. Flash was available for years and it was only used in limited domains. Active-X was available. PNACL is available. asm.js is available, and webasm doesn't offer much more than asm.js in the near future.
>
> You can wish, but certainly not guarantee.

You seem to have missed the discussion above.  I guessed that they were allowing webasm to directly manipulate the DOM, rather than having to call out to javascript to do it.  Reading a bit more now, I don't think they're doing that.  In any case, none of the latter three technologies that allow using different programming languages were ever ubiquitous, the importance of which Wyatt and I discussed above.  Just by webasm being implemented in all major browsers, it would certainly lead to a _lot_ less javascript getting written, once devs actually have a choice of other languages, even if they'd still have to wrap javascript calls for DOM manipulation.

As for Java and Flash, they were very widely used, despite being slow and in their own little world inside the browser.  It was Flash that finally brought video widely to the browser, not the few HTML tags, codecs, and players that were there before.  And neither is as integrated into the web stack as webasm will be.

>> Actually, that's one of the big problems with the more dynamic model: it breaks search engine indexing.  How does the crawler have any idea how to navigate an app UI and generate URLs that are meaningful, if they're even made available by the app?
>
> Google provide ways to index dynamic apps, but it is more work. So it costs more in developer time.

Right, that is the problem.  The old static page model was naturally geared towards a search engine, but the new dynamic model isn't.  That's a big problem for google, whether they realize it or not.

>> enough.  But as I noted earlier, the canvas tag doesn't even support hyperlinks natively, which is a pretty big omission for a web technology.
>
> Not sure what you mean by that? You trigger on the click and load the target page? Or if you wish, you can overlay hyper-link rectangles on top of the canvas.

I meant that it'd be nice if linking to parts of the canvas had a bit nicer support than this:

http://stackoverflow.com/questions/6215841/create-links-in-html-canvas

OK, that's not going to make something so low-level as a canvas magically that much better-integrated into the web, but it might help.  I haven't messed with canvas much, but it's interesting how little it's been used, despite all the hype it got when it was first released.

> The current model is quite flexible, you can mix technologies. Perhaps too flexible.

That's what you do when you mash a bunch of disparate technologies together: make them mixable and flexible and let the devs deal with all the complexity and bugs. :)

>> actually work. As I already noted, SVG doesn't have to be text to be "embedded."
>
> It has to be part of the DOM. Parsing is not the main issue.

If speed of parsing and analyzing weren't one of the main issues, why are they even taking this webasm binary approach?  A binary SVG can be made part of the DOM too once it's parsed.

>> Very responsive because they're made up of trivially simple line art, perhaps.
>
> Trivial is relative. You can't have full-on photon-based simulation. You can have an advanced webGL shader if you want. As long as the renderer is the bottleneck you have to design for the renderer, no matter what kind of renderer you have. And you have many:
>
> 1. HTML5/CSS
> 2. HTML5/CSS GPU transforms
> 3. SVG
> 4. Canvas2D
> 5. WebGL.
>
> That's five different rendering strategies with different performance characteristics and you have to design your graphics for each one of them.

We were talking about the original web stack and SVG, ie 1-3 in you list.  WebGL is a whole different beast.

>>> attach event-listeners to parts of the SVG. Not having HTML and SVG in the same source would be very confusing.
>>
>> It wouldn't be confusing at all.  You'd simply do all that in your text SVG authoring format and HTML on your side, then compile SVG to a binary encoding on the server and send that to the browser.
>
> That would just be a different encoding of HTML5, if parsing was a major bottleneck, that might be a point. But it would have to coexist with the textual version and developers would only upgrade if it solves a problem.

It's only a different encoding of SVG, which the browser would then integrate into the DOM.  At this point, you'd still have to have the text fallback, as you say, because they already put it in, but an option for binary encoding would significantly increase its use.  Of course, as Wyatt said, SVG has a lot of other problems too.

> In the scripting API using text as values might be an issue, but that's a different topic.

Nothing that couldn't be made to work with the appropriate binary encoding.

On Sunday, 21 June 2015 at 10:13:22 UTC, Kagamin wrote:
> Do you think it's wise to ignore 2 billion users? The size of the mobile market doesn't mean you can target it entirely. The article suggests currently we have era of services and services are clustered by culture, which means you can't target users outside of your cultural cluster, while desktop applications usually target entire desktop market without exceptions.

Apparently most new apps nowadays are ignoring that legacy desktop market. :) My point was that as mobile devices become usable with larger monitors, that desktop market is going to collapse.  As for cultural clusters, that's changing as they're now starting to bleed into each other: look at Office on Android/iOS and the multi-window stuff coming to mobile devices.

>> All the major mobile vendors are working on multi-window implementations which will soon allow you to plug your mobile device into a dock that connects to a monitor/keyboard/trackpad on your desk and run your mobile apps in a similar way to the desktop: Apple's just-announced multi-window feature to go along with their coming iPad Pro, Google's in-development multi-window implementation that has been found in the Android M build, and Microsoft's recently announced Continuum for mobile devices, that lets you plug your Windows Phone into a monitor and use Office with a desktop UI.
>
> Are you going to support windows phone?

No, of course not. :) But I'd been saying for a year or two that MS was dumb not to put desktop UIs and apps on their mobile devices, so you could use them with a monitor, and they're finally fixing that.  I can't imagine anyone actually wants to use Excel or Word on a touchscreen, I have no idea why they made such a big deal out of that.  Will it save Windows Mobile?  I doubt it, but given the strength of their office suite, it might sustain it a bit longer.

>> What this means is that people will soon be using their mobile devices for almost everything and desktop computers are effectively dead. :) Now, workstations were killed off by PCs and they still sell a couple million worldwide.  Similarly, there will always be a niche for PCs and mainframes.  It's just a small niche.
>
> It will be desktop for all practical purposes, just more constrained in resources. Mobile platform will embrace two unrelated ecosystems, and you will still have to choose which ecosystem you target, and since desktop is a minority, why you would care about mobile desktop? It will be minority for all the same reasons that make desktop minority.

That's like saying current PCs are "mainframes for all practical purposes, just more constrained in resources," you honestly believe that too? ;)

I disagree that the ecosystems are unrelated, though I agree that they're different, but yes, the desktop UI on mobile devices will definitely be a minority.  Most people using computers just want to read a little, hit a couple buttons, and listen to music or watch a video once in awhile, anywhere they are.  That's what mobile devices are for.  The former dominant use case for computers, creating content or getting work done, are a small part of what computers are bought and used for nowadays.

So yes, the desktop UI is a niche, but a moderately large niche that is about to move to mobile devices also.  There will always be a tiny niche of users that sticks with desktops/laptops, workstations, and mainframes.

On Sunday, 21 June 2015 at 10:29:26 UTC, Kagamin wrote:
> On Saturday, 20 June 2015 at 19:00:08 UTC, Joakim wrote:
>> On Saturday, 20 June 2015 at 15:21:29 UTC, Kagamin wrote:
>>> High DPI settings screw up native UI too if it's not pixel-precise, and ignoring user preferences is infraction, I'm afraid. And this is where web actually shines: it's designed to adapt gracefully to any user settings. Well, of course when site design strays from how web was designed to work, it runs into problems, that should be obvious.
>>
>> The highest-DPI devices I use nowadays are mobile devices and, in my experience, websites are the ones who most often get it wrong.
>
> I mean only design possibility, which is not taken advantage of in modern web, unfortunately.
>
>>  That's usually related to tiny text, but that affects the overall layout too.
>
> Designers like their 5-pixel fonts and believe everybody will appreciate them. But I think pixel-oriented design is a flawed design choice for web, web wasn't designed to work that way.

It certainly can be hard to get this stuff right on any app platform, whether web or native mobile, with the proliferation of screen sizes, viewing distances, and DPIs these days, as Nick pointed out with the smart TV example above.  But I have to wonder if most of those small-font sites/apps render right on anything other than a _single_ device, which means their devs are certainly not dealing with that complexity at all.

On Saturday, 20 June 2015 at 20:31:35 UTC, Nick Sabalausky wrote:
> Interestingly, Canonical could've beat everyone to the punch here. They had what was basically "continuum for linux" more or less already working, but then...they just...what, threw it in the trash bin or something? I dunno, I don't quite get Canonical sometimes.

Threw what in the trash-bin? I'm writing this post from a commercially-purchased Ubuntu phone, and a "fully-converged" device is officially announced from BQ for later this year.

On Sunday, 21 June 2015 at 11:56:13 UTC, Joakim wrote:
> On Sunday, 21 June 2015 at 10:13:22 UTC, Kagamin wrote:
>> Do you think it's wise to ignore 2 billion users? The size of the mobile market doesn't mean you can target it entirely. The article suggests currently we have era of services and services are clustered by culture, which means you can't target users outside of your cultural cluster, while desktop applications usually target entire desktop market without exceptions.
>
> Apparently most new apps nowadays are ignoring that legacy desktop market.

You mean services?

> As for cultural clusters, that's changing as they're now starting to bleed into each other: look at Office on Android/iOS and the multi-window stuff coming to mobile devices.

Huh? Cultural clusters like nation, country clusters. If you make US-oriented news service, you can't target even EU users not speaking about China.

>> It will be desktop for all practical purposes, just more constrained in resources. Mobile platform will embrace two unrelated ecosystems, and you will still have to choose which ecosystem you target, and since desktop is a minority, why you would care about mobile desktop? It will be minority for all the same reasons that make desktop minority.
>
> That's like saying current PCs are "mainframes for all practical purposes, just more constrained in resources," you honestly believe that too? ;)

And how do they differ?

> The former dominant use case for computers, creating content or getting work done, are a small part of what computers are bought and used for nowadays.

Yes, if smartphones do that, they will become desktop.

> So yes, the desktop UI is a niche, but a moderately large niche that is about to move to mobile devices also.

Yes, but your claim is that desktop will die, not move.

> devs are certainly not dealing with that complexity at all.

Yes, that's the problem with web: devs can't get web right for decades already, that's also one of the reasons for mobile apps to exist.

On Sunday, 21 June 2015 at 13:51:06 UTC, Kagamin wrote:
> On Sunday, 21 June 2015 at 11:56:13 UTC, Joakim wrote:
>> Apparently most new apps nowadays are ignoring that legacy desktop market.
>
> You mean services?

I meant mobile apps, many of which are services, but even stand-alone apps with no network component.

>> As for cultural clusters, that's changing as they're now starting to bleed into each other: look at Office on Android/iOS and the multi-window stuff coming to mobile devices.
>
> Huh? Cultural clusters like nation, country clusters. If you make US-oriented news service, you can't target even EU users not speaking about China.

Sorry, I didn't read the conclusion of that link I gave you: I just linked it for the large graph showing and forecasting the number of global smartphone users.  I based my response just on your comment and thought you meant a culture for desktop apps vs. another for mobile apps.

If you're talking about geographical cultural clusters, I agree that services are getting more fragmented as the rest of the world comes online, and since those mobile devices and services are killing off the desktop, that global desktop app market is going away.

>> That's like saying current PCs are "mainframes for all practical purposes, just more constrained in resources," you honestly believe that too? ;)
>
> And how do they differ?

That doesn't answer my question. :) As for yours, well, for one, a program written for an AIX POWER mainframe isn't going to run unmodified on a PC.  It's not going to have a desktop UI either.  They're considered completely different categories of computers, even though they're all computers.

>> The former dominant use case for computers, creating content or getting work done, are a small part of what computers are bought and used for nowadays.
>
> Yes, if smartphones do that, they will become desktop.

I see, so if I start transcribing a novel by voice to the on-board computer in my car on the way to work every day, it becomes a desktop, because I'd have previously written it up in desktop Word?  Just because a device takes on some functions that you previously did with a desktop doesn't make it a desktop.

>> So yes, the desktop UI is a niche, but a moderately large niche that is about to move to mobile devices also.
>
> Yes, but your claim is that desktop will die, not move.

I was very specific in my claims, at least to Nick above.  I said the desktop/laptop form factors and OSs will die out, but multi-window UIs similar to desktop UIs will live on.  That is _not_ the desktop moving on, only something like its UI.

>> devs are certainly not dealing with that complexity at all.
>
> Yes, that's the problem with web: devs can't get web right for decades already, that's also one of the reasons for mobile apps to exist.

I was talking about both web and native here.  High-DPI resolutions have caused me problems with native desktop and mobile apps also.  Windows seemed to come particularly late to handling those better.

As for the web, anytime you get outside trivial layouts, it gets fairly complex quickly, particularly for cross-browser compatibility.  The web stack of HTML/CSS/JS is just not well-suited for app UIs.

On 06/21/2015 09:45 AM, Joseph Rushton Wakeling  wrote:
> On Saturday, 20 June 2015 at 20:31:35 UTC, Nick Sabalausky wrote:
>> Interestingly, Canonical could've beat everyone to the punch here.
>> They had what was basically "continuum for linux" more or less already
>> working, but then...they just...what, threw it in the trash bin or
>> something? I dunno, I don't quite get Canonical sometimes.
>
> Threw what in the trash-bin?

https://en.wikipedia.org/wiki/Ubuntu_for_Android

Though I may very well be missing something.

> I'm writing this post from a
> commercially-purchased Ubuntu phone, and a "fully-converged" device is
> officially announced from BQ for later this year.