Re: Web Wishes

On 01/07/2013 13:22 , François REMY wrote:
>> Say if you're embedding Photoshop to edit an image with it, then the
>> embed page just shows the picture and Photoshop is launched as usual.
>> (And you can get it to cooperate without it knowing it by watching the
>> file and sending events every time it's saved — imperfect but hey, we
>> have to work in steps.)
>
> Okay but what's the point? How is that better than leaving the UA do the
> hard work of displaying the app the way is the most natural to the
> platform? On Windows 8, the Share charm is displayed the same way every
> time and is totally outside of control of the share initiator, and
> that's absolutely awesome because this uniformity brings a lot of
> potential for innovation to the platform instead of to the app. They
> added new sharing possibilities to Windows 8.1 with no need for any
> change in the apps because Microsoft was in total control of the
> experience. If it was up to apps to choose the size and location the
> sharing control, maybe some would have fitted the box in a way that made
> it impossible for the OS to show more on-screen content. Also, the user
> looses the benefits of consitency.

If you want basic things like sharing, then sure enough just launch them 
using whatever the platform provides (which I'm guessing is Microsoft's 
notion in suggesting launchURL()). I don't see a web developer trying to 
lay something out if there's no need to.

In turn that shouldn't have UX issues since it ought to just be whatever 
the platform proposes.

But embedding is the right thing for many other cases. For instance, I 
wish no application would ever show me its own text editing interface 
(unless it's really special somehow), but rather it should always use 
the one that I prefer from my text editor. I want that embedded.

Every single mail client sucks horribly. Starting one from scratch is 
just too much work, but many have components that actually work well. 
I've like to expose my email to a mailbox lister, a mailbox viewer, a 
message viewer, a message editor, an address book component with access 
to my contacts, etc.

In other words, let people innovate in apps in small chunks, rather than 
require someone take over a large project (or even find unlikely 
extension points in an existing one). It's not just the technology that 
should be extensible.

> (however, this should probably be discussed inside the TAG group as it's
> all about API design, I'm not sure it's really linked to the charter of
> this working group)

Well, it makes the Web extensible along some lines that other approaches 
don't yet :)

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 1 July 2013 12:00:17 UTC