Gears Application File Associations
12 views
Skip to first unread message
Eric-Sebastien Lachance
Oct 6, 2008, 7:28:17 AM10/6/08
to Gears Users
I'm surprised that I have not see this anywhere in the docs, faqs or
elsewhere I looked.
I've recently become a big fan of one online app that uses Gears (Zoho
busines suite) and I am attempting to sell this as a replacement to
Microsoft Office to my VP of IT. Within the "disadvantages" or the
"against" points, there is obviously online availability, data privacy
and other concerns.
But there is one thing that Zoho and other Gears applications do *not*
do and that is the basics of any application in use today on a
computer: File Associations. Let's say I'm using Zoho (or Google Docs
for that matter) as my main Document editor. I received Word documents
everyday from candidates that want a job with me, and I need to open
those files.
What user will want to save the document from their email, floppy,
website or USB key, then open the application, select "import", then
"browse" to get to the file in order to open it? None! No one wants
this sort of long, complicated method of opening files when right now,
all they are doing is simply double-clicking on the Word file from
their explorer, or from Outlook, or from an in-house application like
the one we use for resume storing/applicant database.
I would strongly suggest that Google gets on this case as soon as
possible - to offer file associations with an online application from
the Windows Explorer window in order for users to easily open their
current files with the new application without hassle.
And if that's already possible... Document it!
Cheers,
Eric-Sebastien Lachance
elsewhere I looked.
I've recently become a big fan of one online app that uses Gears (Zoho
busines suite) and I am attempting to sell this as a replacement to
Microsoft Office to my VP of IT. Within the "disadvantages" or the
"against" points, there is obviously online availability, data privacy
and other concerns.
But there is one thing that Zoho and other Gears applications do *not*
do and that is the basics of any application in use today on a
computer: File Associations. Let's say I'm using Zoho (or Google Docs
for that matter) as my main Document editor. I received Word documents
everyday from candidates that want a job with me, and I need to open
those files.
What user will want to save the document from their email, floppy,
website or USB key, then open the application, select "import", then
"browse" to get to the file in order to open it? None! No one wants
this sort of long, complicated method of opening files when right now,
all they are doing is simply double-clicking on the Word file from
their explorer, or from Outlook, or from an in-house application like
the one we use for resume storing/applicant database.
I would strongly suggest that Google gets on this case as soon as
possible - to offer file associations with an online application from
the Windows Explorer window in order for users to easily open their
current files with the new application without hassle.
And if that's already possible... Document it!
Cheers,
Eric-Sebastien Lachance
Ben Lisbakken
Oct 6, 2008, 5:11:44 PM10/6/08
to gears-users
Hey Eric --
As far as I know, we don't have a feature like that. Sounds pretty compelling though! I think this is a great idea. You should put it on the issue tracker:
For right now, the best that there is is the Desktop API which lets you have shortcuts on the desktop to a URL. This still keeps the user a few clicks away from importing, though.
-Ben
2008/10/6 Eric-Sebastien Lachance <eslac...@gmail.com>
Eric-Sebastien Lachance
Oct 8, 2008, 9:57:27 AM10/8/08
to Gears Users
Ben...
I strongly hope that I'm not the first one to have thought of this,
because if I am that should merit me a job at Google (got a
"Brainstormer" position open?) :P
Nah, seriously though, if any online application is to become a
replacement for a local one (if Docs wants to replace Word, GMail
replace Outlook) then in a sense you have no choice but to mimic not
only the software functionality, but the OS functionality. Having a
file association to a software is a behavior that people are just used
to.
In order to offer a service for the "masses", you have to think like
the masses, not like geeks!
Cheers,
Eric.
I strongly hope that I'm not the first one to have thought of this,
because if I am that should merit me a job at Google (got a
"Brainstormer" position open?) :P
Nah, seriously though, if any online application is to become a
replacement for a local one (if Docs wants to replace Word, GMail
replace Outlook) then in a sense you have no choice but to mimic not
only the software functionality, but the OS functionality. Having a
file association to a software is a behavior that people are just used
to.
In order to offer a service for the "masses", you have to think like
the masses, not like geeks!
Cheers,
Eric.
Nicolas Roard
Oct 8, 2008, 10:40:48 AM10/8/08
to gears...@googlegroups.com
On Wed, Oct 8, 2008 at 2:57 PM, Eric-Sebastien Lachance
<eslac...@gmail.com> wrote:
>
> Ben...
>
> I strongly hope that I'm not the first one to have thought of this,
> because if I am that should merit me a job at Google (got a
> "Brainstormer" position open?) :P
>
> Nah, seriously though, if any online application is to become a
> replacement for a local one (if Docs wants to replace Word, GMail
> replace Outlook) then in a sense you have no choice but to mimic not
> only the software functionality, but the OS functionality. Having a
> file association to a software is a behavior that people are just used
> to.
>
> In order to offer a service for the "masses", you have to think like
> the masses, not like geeks!
<eslac...@gmail.com> wrote:
>
> Ben...
>
> I strongly hope that I'm not the first one to have thought of this,
> because if I am that should merit me a job at Google (got a
> "Brainstormer" position open?) :P
>
> Nah, seriously though, if any online application is to become a
> replacement for a local one (if Docs wants to replace Word, GMail
> replace Outlook) then in a sense you have no choice but to mimic not
> only the software functionality, but the OS functionality. Having a
> file association to a software is a behavior that people are just used
> to.
>
> In order to offer a service for the "masses", you have to think like
> the masses, not like geeks!
I think this is a good idea; there are various ways that could be implemented.
e.g. we could create a blob with the file, and have an additional method to the
filepicker api that would returns that blob (so webapps upon starting could
call a getParameter() method or something like that).
As Ben said, what you can do right now if you simply want "documents" on your
desktop (vs opening existing file types) for your webapp, you should be able
to create shortcuts using the desktop api (then it's just a matter for
your webapp
to create shortcuts with url containing the document id so that it can
present it to the user).
--
Nicolas Roard
Google UK London
Eric-Sebastien Lachance
Oct 8, 2008, 11:50:33 AM10/8/08
to Gears Users
Nicolas,
Your solution for opening the webapp documents (like a doc residing on
google docs) from the desktop is good, but it's the contrary to what I
mention, e.g. opening a local doc from the webapp. This is especially
important when an organization (such as us) have 300 employees
managing hundreds of office documents on a shared drive, and a
transitional period is required to switch to a new system.
I do see what you mean in your first paragraph about sending a
parameter to the webapp. Though I haven't worked with the code (I'm a
client/user, not a developer), I see the logic in it.
I've followed Ben's suggestion and opened an issue (http://
code.google.com/p/gears/issues/detail?id=745) for this, but here's how
I see it working:
User double-clicks on the file, and selects to open it with Google
Gears. Gears sees the file and asks with what "WebApp" you want to
open it with, where you can select the one you use (for example, I can
select between Zoho Writer and Google Docs at this point). It's an
extra setup step, yes, but this would be the ideal way of doing things
I think. Perhaps a Gears interface to manage the file associations
would be a good idea also, to do the process in a reverse order
(create a new association, select the file type, select the WebApp.
Thanks for your time guys, I hope this becomes a reality soon!
Cheers,
Eric.
Your solution for opening the webapp documents (like a doc residing on
google docs) from the desktop is good, but it's the contrary to what I
mention, e.g. opening a local doc from the webapp. This is especially
important when an organization (such as us) have 300 employees
managing hundreds of office documents on a shared drive, and a
transitional period is required to switch to a new system.
I do see what you mean in your first paragraph about sending a
parameter to the webapp. Though I haven't worked with the code (I'm a
client/user, not a developer), I see the logic in it.
I've followed Ben's suggestion and opened an issue (http://
code.google.com/p/gears/issues/detail?id=745) for this, but here's how
I see it working:
User double-clicks on the file, and selects to open it with Google
Gears. Gears sees the file and asks with what "WebApp" you want to
open it with, where you can select the one you use (for example, I can
select between Zoho Writer and Google Docs at this point). It's an
extra setup step, yes, but this would be the ideal way of doing things
I think. Perhaps a Gears interface to manage the file associations
would be a good idea also, to do the process in a reverse order
(create a new association, select the file type, select the WebApp.
Thanks for your time guys, I hope this becomes a reality soon!
Cheers,
Eric.
Chris Prince
Oct 8, 2008, 1:30:03 PM10/8/08
to gears...@googlegroups.com
Hi Eric,
File associations are idea we have discussed briefly. A couple thoughts:
* Rather than prompting the user on unhandled file types, I think
applications would want to register for file associations. Two
reasons:
- Apps may want to register for already-handled types.
- Apps that don't register for a type likely won't be able to do
anything useful with it (if the user creates the file association).
* System file associations would probably need a permission prompt,
similar to desktop shortcuts.
* We would need to figure out how to expose the file data to the web app.
A handler like onFileOpen(blob) makes the most sense to me right now.
I've also heard talk of posting to a URL, but getting the protocol right
sounds tricky.
magixman
Oct 14, 2008, 11:10:16 PM10/14/08
to Gears Users
Chris,
The logic to parse an Office document is going to be on the server for
now. Yes someday a JS application could do this but for now all web-
based applications that eat Office documents (Zoho, Google Documents
and soon our own) do so with various libraries that run only on the
server. So this speaks to using much of the same mechanism that you
currently use for uploading "captured files". Here is a scenario off
the top of my head:
An application registers a file type and and a URL to be invoked when
the file type is clicked. This is subject to the restrictions you
mention. The file is then captured as though it was uploaded offline
and is available to the FileSubmitter class. You can auto-generate a
URL for the resource using a GUID plus the actual name of the file and
pass the URL to the application via the OnFileOpen callback as you
describe (assuming the URL is running somewhere). If the application
is online it can upload the file and parse it immediately and if it is
offline it can promise that it will do so as soon as the internet
connection is restored.
On registration I do think you need a very explicit dialog to let the
user know that "files of type xxx will be sent to application yyy. Do
you trust yyy?". One final thought. As web applications gain
acceptance many users will have Microsoft Office or Open Office
installed and so it might make sense that an application can register
a file type for an already-handled type and when a file of that type
is clicked on, the user is then offered a choice of destinations via a
popup menu. This is just expanding on asterisk 1, dash 1.
This would be a very "game changing" feature for those off us
implementing applications in the office productivity space.
....Sam
The logic to parse an Office document is going to be on the server for
now. Yes someday a JS application could do this but for now all web-
based applications that eat Office documents (Zoho, Google Documents
and soon our own) do so with various libraries that run only on the
server. So this speaks to using much of the same mechanism that you
currently use for uploading "captured files". Here is a scenario off
the top of my head:
An application registers a file type and and a URL to be invoked when
the file type is clicked. This is subject to the restrictions you
mention. The file is then captured as though it was uploaded offline
and is available to the FileSubmitter class. You can auto-generate a
URL for the resource using a GUID plus the actual name of the file and
pass the URL to the application via the OnFileOpen callback as you
describe (assuming the URL is running somewhere). If the application
is online it can upload the file and parse it immediately and if it is
offline it can promise that it will do so as soon as the internet
connection is restored.
On registration I do think you need a very explicit dialog to let the
user know that "files of type xxx will be sent to application yyy. Do
you trust yyy?". One final thought. As web applications gain
acceptance many users will have Microsoft Office or Open Office
installed and so it might make sense that an application can register
a file type for an already-handled type and when a file of that type
is clicked on, the user is then offered a choice of destinations via a
popup menu. This is just expanding on asterisk 1, dash 1.
This would be a very "game changing" feature for those off us
implementing applications in the office productivity space.
....Sam
On Oct 8, 1:30 pm, "Chris Prince" <cpri...@google.com> wrote:
> Hi Eric,
>
> File associations are idea we have discussed briefly. A couple thoughts:
>
> * Rather than prompting the user on unhandled file types, I think
> applications would want to register for file associations. Two
> reasons:
> - Apps may want to register for already-handled types.
> - Apps that don't register for a type likely won't be able to do
> anything useful with it (if the user creates the file association).
>
> * System file associations would probably need a permission prompt,
> similar to desktop shortcuts.
>
> * We would need to figure out how to expose the file data to the web app.
> A handler like onFileOpen(blob) makes the most sense to me right now.
> I've also heard talk of posting to a URL, but getting the protocol right
> sounds tricky.
>
> On Wed, Oct 8, 2008 at 8:50 AM, Eric-Sebastien Lachance
>
> Hi Eric,
>
> File associations are idea we have discussed briefly. A couple thoughts:
>
> * Rather than prompting the user on unhandled file types, I think
> applications would want to register for file associations. Two
> reasons:
> - Apps may want to register for already-handled types.
> - Apps that don't register for a type likely won't be able to do
> anything useful with it (if the user creates the file association).
>
> * System file associations would probably need a permission prompt,
> similar to desktop shortcuts.
>
> * We would need to figure out how to expose the file data to the web app.
> A handler like onFileOpen(blob) makes the most sense to me right now.
> I've also heard talk of posting to a URL, but getting the protocol right
> sounds tricky.
>
> On Wed, Oct 8, 2008 at 8:50 AM, Eric-Sebastien Lachance
>
Reply all
Reply to author
Forward
0 new messages