Re: [Nautilus-list] Allowing view components to provide editing (UI and architecture issues)
- From: Maciej Stachowiak <mjs noisehavoc org>
- To: Havoc Pennington <hp redhat com>
- Cc: Maciej Stachowiak <mjs noisehavoc org>, nautilus-list lists eazel com
- Subject: Re: [Nautilus-list] Allowing view components to provide editing (UI and architecture issues)
- Date: Sun, 29 Jul 2001 20:55:07 -0700
On 26Jul2001 11:01AM (-0400), Havoc Pennington wrote:
>
> Maciej Stachowiak <mjs noisehavoc org> writes:
> >
> > I decided to start working on adding the ability to make components
> > editable and have a reasonable UI for saving and such. Since one of
> > the top usability concerns with Nautilus according to Sun's report is
> > the fact that the text view does not allow editing, I figure the best
> > solution is to make it allow editing.
> >
>
> Just to play devil's advocate, another solution is to open text files
> in a separate application, instead of in an embedded view.
I agree that making an application the default action for text files
would also solve the problem. But I guess it would amount to sort of
giving up on the whole view concncept as applied to non-directories.
> It's never been clear to me where views end and apps begin - Windows
> Explorer transforms into IE when you view HTML, it doesn't do
> something simple like embed an HTML component and merge menus, the
> whole shell radically changes to a full-blown web browser.
I don't have a windows box handy so I haven't really tried this. What
kind of things change besides the main content area, the toolbar, and
the menus?
> I think that's basically what you have to do if you go down the road
> of always using views instead of apps; you have to transform Nautilus
> fully into the app.
I don't think it's necessarily the case that it needs to transform
into a complex, full-featured app. For instance, most of the time when
I open images I want something along the lines of Electric Eyes or
EOG, not The Gimp. Similarly, most of the time when viewing HTML I
want a web browser, not an HTML editing/publishing/workflow system.
It just happens that for text the simple minimal level of
functionality that you need for quick viewing situations like this
includes basic editing.
> Right now isn't the line between views and apps that you can only use
> views to view, not to edit?
Well really the only unambiguous line is that views are embedded in
the Nautilus window and apps run separately. The directory views all
allow you to, in some sense, "edit" the directory, although the
changes are all applied instantly so these issues about saving do not
matter. I guess live editing in the text component might be an OK UI,
but it would be kind of experimental and would require many layers of
undo to avoid problems caused by accidental changes.
I don't know if there is an official logical boundary to draw between
views and apps. To me a view is ideally just a light-weight, minimal
thing, but it does seem that in cases like directories and text,
editing is part of that base set of functionality.
> So if you can edit, when does the user expect an app and when do
> they expect a view, if they double-click an icon?
Right now there's no good way for the user to know what to expect.
Adding editing to some views would make this no worse and no better I
think.
> I don't know the best solution, but it confuses me, so maybe it
> confuses users too, who knows. ;-)
I agree it's a confusing area of the design. I don't really want to
rework it from scratch though, I just want to address this one
particular usability issue.
- Maciej
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]