On 06/20/2015 12:20 PM, ketmar wrote:
> On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Grøstad wrote:
>
>> On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
>>> it was designed to ignore that fact altogether. html/css layouting is a
>>> pitiful attempt and barely usable. bwah, it can't even do normal
>>> constraints!
>>
>> Hmmm, what do you mean by normal constraints?
>
> google://cassowary
>
> that is a *real* constraint engine. what we have in css is a half-assed
> attemt to emulate the real engine without the engine itself.
>

I can see why people aren't familiar with that and it's approach: There's zero front-page examples, and any basic "examples 101", "how to use it" seem well-buried. Most people are gonna take one brief look and move on. It seems to really need some better PR.

On Sat, 20 Jun 2015 12:32:11 -0400, Nick Sabalausky wrote:

> On 06/20/2015 12:20 PM, ketmar wrote:
>> On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Grøstad wrote:
>>
>>> On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
>>>> it was designed to ignore that fact altogether. html/css layouting is a pitiful attempt and barely usable. bwah, it can't even do normal constraints!
>>>
>>> Hmmm, what do you mean by normal constraints?
>>
>> google://cassowary
>>
>> that is a *real* constraint engine. what we have in css is a half-assed attemt to emulate the real engine without the engine itself.
>>
>>
> I can see why people aren't familiar with that and it's approach: There's zero front-page examples, and any basic "examples 101", "how to use it" seem well-buried. Most people are gonna take one brief look and move on. It seems to really need some better PR.

it's actually a tool for toolkit builders, not for end users. cassowary itself is only a solver, it doesn't even have syntax to setup constraints (toolkit builder must invent an implement one).

so it's hard to make example for it which doesn't resemble a wall of text several pages long only to layout three elements.

the real power of cassowary is it's dynamic constraint solver. but it needs to be combined with user-friendly constraint syntax, or it will be unusable. so cassowary authors have to write their own toolkit only to show some impressive examples on site! ;-)

besides, cassowary comes from "university culture", where user-friendly presentations are bad or non-existent.


tl;dr: i completely agree with you! ;-)

On Saturday, 20 June 2015 at 16:23:47 UTC, ketmar wrote:
> On Sat, 20 Jun 2015 16:18:28 +0000, Kagamin wrote:
>
>> Windows API would be similar to X11, where you just specify everything in pixels and toolkits building on top of it manually do all the recomputations and layout policies, not the UI server.
>
> only in windows "toolkit" is built into system. and it can't do anything except pixels and stupid "dialog units".

Well, it's just windows api was simple enough to be usable directly, while X11 didn't fly that way and didn't receive development since everybody used toolkits and all features were implemented in toolkits, which in the end used X11 as plain canvas rather than windowing system.

>> And then it's still not simple: with small font you can put a lot of information into a window, which simply won't fit with bigger font size, in this case web gets scrolled naturally, while native UI clunks interface and truncates strings trying to fit it into the window.
>
> i lol'd. a typical windows rant, where "toolkits" still doesn't know about such things as "preferred size", "minimal size", and can't add scrolling if necessary, choosing to make controls smaller and smaller instead.

Knowing minimal size won't help you if the amount of information simply doesn't fit. Dialogs can be scrolled, but master-detail views can't: master and detail views already reserve scrolling for themselves, so it can't be reused for the entire window, well, at least it won't work naturally.

On Friday, 19 June 2015 at 15:52:09 UTC, Ola Fosheim Grøstad wrote:
>> across sites.  That does nothing to integrate the old page/hyperlink model of the web with the new dynamic HTML5 model, but as Nick said, simply piles more of the dynamic stuff on top.
>
> Actually, it does, as the logic is moved more into elements. Like Angular and Polymer.

I probably haven't been clear enough about what I mean.  The original model for the web was a bunch of hyperlinked pages/documents.  But that model increasingly breaks down as you make the page more dynamic.  What are you linking to anymore: a page, an app, or a widget within the app?  Now you have to freeze all state within an app then link to it, like the generated links on Google Maps or when you save a document in Word.

As the browser tries to mesh these two worlds, the old-fashioned static hyperlinked pages and the new dynamic widgets of AJAX and HTML5, rifts crop up.  The recent web components efforts you highlight do not address this at all, they merely make it easier to build more dynamic webapps.  But in doing so, they actually bring the problems I'm talking about more to the fore.

>> That actually makes some sense for a document format, which is what HTML originally was.  It makes no sense for a vector graphics format like SVG, where efficiency is key.
>
> I'd think the opposite, that binary format makes sense for PDF since it is an enduser format, but it is easier to debug when text so it is probably text for the same reasons as SVG.

My point was that text makes some sense for the layout of a document format, but efficiency is key in vector graphics, so you always want to go binary there.

> For SVG I want flexibility and transparency. It would be counterproductive if it was not in XML. Editing would be horrible. And yes, I edit SVG by hand, PDF too. I don't think I've ever used SVG or built PDF generators without manually editing either format as raw text.

Then have SVG be an authoring format that is subsequently "compiled" down to an efficient binary encoding for distribution. There is _zero_ reason for text SVG to be the actual end-user format.  I bet a lot of the bloat issues that Wyatt pointed out are exactly because of this.

>> Because writing it once in HTML/CSS/JS takes you much longer than writing it in Java, while being less responsive, then you
>
> Dunno about less responsive. Java apps often feel more sluggish than well written web apps. Java is probably better for larger programs, but most programs aren't large. Many programs are just simple interfaces to online databases.

On mobile devices, I've been hit by plenty of sluggishness from both, just more so in the browser.

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.  That's usually related to tiny text, but that affects the overall layout too.

> I didn't really try to write java, but my impression is that java usually requires huge amounts of boilerplate code, while web is usually succinct.

I don't find HTML/CSS/JS succinct or easy to get right, the latter of which writing a Java/Android UI is at least better at.  Of course, the Android devs had to go muff that up by adding XML into the mix.

> Dunno, I don't see there losses, maybe because they only happen on mobile. Yeah, you said nothing about how this is related to desktop as if it doesn't exist.

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

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.

On Saturday, 20 June 2015 at 19:00:08 UTC, Joakim wrote:
> I probably haven't been clear enough about what I mean.  The original model for the web was a bunch of hyperlinked pages/documents.  But that model increasingly breaks down as you make the page more dynamic.  What are you linking to anymore: a page, an app, or a widget within the app?

Yes, but would it be better to just have pages and no apps? I don't think so. When I build an order system it is very useful to build it like an app.

The fact is that networking bandwidth is now so large that you often can download the catalog for an online shop at once, compressed it is the size of an image...

Of course, the app programmer will have to decide how that maps to urls, or if it should map to urls. You can do it with the hash-tag or by changing the visible url without reloading (on modern browsers). I do that if it is important.

> widgets of AJAX and HTML5, rifts crop up.  The recent web components efforts you highlight do not address this at all, they merely make it easier to build more dynamic webapps.

It kinda does. Because you can then serve pages with markup that do things that are specific for the site. When you can attach behaviour to tags implicitly you get to build your own markup-language for the site.

> My point was that text makes some sense for the layout of a document format, but efficiency is key in vector graphics, so you always want to go binary there.

If the vector graphic is intricate it will take time to render it. So there is a limit to how much data you want, I don't think text-transmission is the main issue.

> Then have SVG be an authoring format that is subsequently "compiled" down to an efficient binary encoding for distribution. There is _zero_ reason for text SVG to be the actual end-user format.  I bet a lot of the bloat issues that Wyatt pointed out are exactly because of this.

You can do that if you want. Just download binary data and plot it to a canvas.

But there is no way you could introduce binary SVG when using SVG dynamically. That would require specialized binary-format editors for both SVG and HTML. You would basically want binary HTML too, then.

On Saturday, 20 June 2015 at 16:20:31 UTC, ketmar wrote:
> On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Grøstad wrote:
>
>> On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
>>> it was designed to ignore that fact altogether. html/css layouting is a pitiful attempt and barely usable. bwah, it can't even do normal constraints!
>> 
>> Hmmm, what do you mean by normal constraints?
>
> google://cassowary
>
> that is a *real* constraint engine. what we have in css is a half-assed attemt to emulate the real engine without the engine itself.

Keep in mind that a webpage is being rendered while loading…

On 06/20/2015 03:00 PM, Joakim wrote:
>
> As the browser tries to mesh these two worlds, the old-fashioned static
> hyperlinked pages and the new dynamic widgets of AJAX and HTML5, rifts
> crop up.  The recent web components efforts you highlight do not address
> this at all, they merely make it easier to build more dynamic webapps.
> But in doing so, they actually bring the problems I'm talking about more
> to the fore.
>

An excellent example of this is sites like github that actually manage to break the "back" button, even though it's *clearly* a page-based site (that somehow doesn't seem to believe it is).

> The highest-DPI devices I use nowadays are mobile devices and, in my
> experience, websites are the ones who most often get it wrong.  That's
> usually related to tiny text, but that affects the overall layout too.
>

"Smart" TVs also have trouble there:

http://www.quirksmode.org/blog/archives/2014/07/samsung_smart_t.html

(See the section "The viewport", just underneath the photo with a phone held in front of a TV. Erm...speaking of which: <https://semitwist.com/articles/article/view/html-fragment-linking-is-stupid-here-s-the-fix>)


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

People have been looking at the sales trends and predicting for years that mobile will kill of PCs. And all that happened (unsurprisingly, IMO) is that the decline in PC sales simply leveled off.

Mobile will not, and cannot, replace traditional laptops/desktops (as opposed to merely cooexisting with them as is the case right now) until if/when they finally incorporate all the usability and features of laptops/desktops. Obviously they're not there right *now* yet. But as for the future...

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

I don't think "phones/tablets replacing desktops/laptops" is an entirely accurate way of describing how that will happen (if it does).  More like "phones/tablets and desktops/laptops will converge into a hybrid".

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.

MS, oddly enough, seems to have the highest chance of succeeding at this, as desktop/mobile convergence has been their big goal since Win8. And then Win9 (erm, I mean 10) cleans up some of the mess Win8 left. (Not that I like metro or what the metro "theme" has done to the desktop side of windows, even in Win9^H10, but that's beside the point here.)

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.

On Saturday, 20 June 2015 at 19:39:06 UTC, Ola Fosheim Grøstad wrote:
> Yes, but would it be better to just have pages and no apps? I don't think so. When I build an order system it is very useful to build it like an app.

No, I'm not arguing for pages at all, I'm saying that model is dead and gone.  I think the hyperlink was the killer feature of the web, but everything else, HTML/CSS/JS, is just detritus accumulated on top, that needs to be thrown away.

> The fact is that networking bandwidth is now so large that you often can download the catalog for an online shop at once, compressed it is the size of an image...

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.

>> widgets of AJAX and HTML5, rifts crop up.  The recent web components efforts you highlight do not address this at all, they merely make it easier to build more dynamic webapps.
>
> It kinda does. Because you can then serve pages with markup that do things that are specific for the site. When you can attach behaviour to tags implicitly you get to build your own markup-language for the site.

Again, none of this helps with the fundamental problem: you are engineering an app UI layout engine into an old-fashioned document format.  You are always going to be constrained by the architectural constraints and inefficiency of the document format.

>> My point was that text makes some sense for the layout of a document format, but efficiency is key in vector graphics, so you always want to go binary there.
>
> If the vector graphic is intricate it will take time to render it. So there is a limit to how much data you want, I don't think text-transmission is the main issue.

Text compression will get you part of the way to lessening the bandwidth, but parsing and analyzing the SVG text will always take longer than if it were binary.  I have not actually profiled an SVG renderer to see where the bottleneck is, but I bet using text plays a big role.

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

> But there is no way you could introduce binary SVG when using SVG dynamically. That would require specialized binary-format editors for both SVG and HTML. You would basically want binary HTML too, then.

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."

However, I have long said that they should have tightened up HTML into a binary format around HTML 3 or so, so that needed to be done on its own anyway.

On Saturday, 20 June 2015 at 20:31:35 UTC, Nick Sabalausky wrote:
> An excellent example of this is sites like github that actually manage to break the "back" button, even though it's *clearly* a page-based site (that somehow doesn't seem to believe it is).

Heh, you don't know how many times that's hit me. :)

> "Smart" TVs also have trouble there:
>
> http://www.quirksmode.org/blog/archives/2014/07/samsung_smart_t.html

Heh, I have never tried to use a browser on a TV, especially since I basically haven't watched a TV screen in the last decade, maybe a couple hours of sports a year.  I just download the same or other online videos and watch them on my computer or mobile devices.

> (See the section "The viewport", just underneath the photo with a phone held in front of a TV. Erm...speaking of which: <https://semitwist.com/articles/article/view/html-fragment-linking-is-stupid-here-s-the-fix>)

Hmm, I had not heard of that fragment linking effort you wrote about.  I agree that in the old page model it'd be better if the user decides what he wants to link to, but in the new dynamic model, that is very hard to implement.

>> 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.
>
> People have been looking at the sales trends and predicting for years that mobile will kill of PCs. And all that happened (unsurprisingly, IMO) is that the decline in PC sales simply leveled off.

Still declining though, just less than it was:

http://www.asymco.com/2014/07/23/is-the-pc-back/

I'd say this is a temporary respite before the final collapse.  The only reason it hasn't happened yet is because mobile devices have not worked well with plugging into a large monitor with a mouse and keyboard, but that is now changing.

> Mobile will not, and cannot, replace traditional laptops/desktops (as opposed to merely cooexisting with them as is the case right now) until if/when they finally incorporate all the usability and features of laptops/desktops. Obviously they're not there right *now* yet. But as for the future...

Sure, but current mobile hardware is about as powerful as desktop/laptop chips from a year or two ago, which is what most people are actually running at work:

http://www.anandtech.com/show/9289/the-nvidia-shield-android-tv-review/3

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.

>> 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.
>>
>> 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.
>
> I don't think "phones/tablets replacing desktops/laptops" is an entirely accurate way of describing how that will happen (if it does).  More like "phones/tablets and desktops/laptops will converge into a hybrid".

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.

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.

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

> MS, oddly enough, seems to have the highest chance of succeeding at this, as desktop/mobile convergence has been their big goal since Win8. And then Win9 (erm, I mean 10) cleans up some of the mess Win8 left. (Not that I like metro or what the metro "theme" has done to the desktop side of windows, even in Win9^H10, but that's beside the point here.)

They certainly seemed to start on it first, but screwed it up in some key ways.  Not allowing the desktop on Windows RT was a big mistake, which they appear to be sort of remedying with their recent Continuum/Universal-app moves.  Ironically, this was one of the few cases when Microsoft was too early, because mobile devices were probably not powerful enough when Windows 8 came out three years ago.

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

I get the sense that they're a small organization that bit off something way too big for them.

On Sunday, 21 June 2015 at 05:42:13 UTC, Joakim wrote:
> No, I'm not arguing for pages at all, I'm saying that model is dead and gone.  I think the hyperlink was the killer feature of the web, but everything else, HTML/CSS/JS, is just detritus accumulated on top, that needs to be thrown away.

Thrown away in favour of what? You need a scene-graph / DOM. CSS makes design much easier than the alternative. JS is evolving into something close to TypeScript.

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

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

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.

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

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).

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

I would have preferred something closer to Microsoft VML which made the vector-graphics part of HTML so that you could just insert a circle anywhere on the screen. But I guess the SVG clip rectangle made implementation of the renderer a lot easier.

On 06/21/2015 01:42 AM, Joakim wrote:
>
> I'd say this is a temporary respite before the final collapse. The only
> reason it hasn't happened yet is because mobile devices have not worked
> well with plugging into a large monitor with a mouse and keyboard, but
> that is now changing.
>
[...]
>
> Sure, but current mobile hardware is about as powerful as desktop/laptop
> chips from a year or two ago, which is what most people are actually
> running at work:
>
> http://www.anandtech.com/show/9289/the-nvidia-shield-android-tv-review/3
>
> 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'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.

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.

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.

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.


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

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.


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

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)...

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.

>> 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 ;)

>> MS, [...]

> They certainly seemed to start on it first, but screwed it up in some
> key ways.  Not allowing the desktop on Windows RT was a big mistake,
> which they appear to be sort of remedying with their recent
> Continuum/Universal-app moves.  Ironically, this was one of the few
> cases when Microsoft was too early, because mobile devices were probably
> not powerful enough when Windows 8 came out three years ago.
>

Yea, totally agree on this MS stuff. Pretty much the point I was making about Win8/Win10.

>> 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.
>
> I get the sense that they're a small organization that bit off something
> way too big for them.

Hmm, yea, that may very well be.