Review Request: rename "import" action to "open as new"

[Jaroslaw Staniek]

On 15 August 2012 15:13, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Tuesday 14 August 2012 Aug, Jaroslaw Staniek wrote:
>
>> Definitely Import and Open has been merged into one in many apps these
>> days.
>
> Well, I don't know. I guess it depends, on the one hand you've got weird separations of import/open and export/save as in gimp, on the other hand, I've seen Kexi's "import, export or send" action (which I think is pretty confusing). I don't want to do a big reevaluation of how the komainwindow-based calligra applications handle this whole concept, just clarify one action by improving the text.
>
> Yeah, that takes it out of the realm of the usual, but I think it would be an improvement.
>
>> Import used to force user to know that the format is 'external' to
>> the application's core functionality.
>
> But it never worked that way. Not in KOffice, not in Calligra, not in other applications like Inkscape that have the traditional set of commands. Import has opened any suitable document in a KOffice or Calligra app for over a decade now, including the native file types.
>
>> Regarding your proposal, I'm in favour of not having anything like "Open as
>> new".
>
> So what's your proposal? Remove the import option? All I propose to do here is to reword an action so it actually fits the bill. Maybe "Open as Unnamed Document" would be even better, though.
>

Dear Boud,
My proposal is to remove the import command for apps that do not have
needs for supporting real import.

What's real import?
We can define import by relatively complex process, one-way transfer
of data and metadata, often possible after a series of answers given
by user. For example in Kexi after a long lookup I put such external
transfers into one common submenu: "Import, Export or Send" (yes,
please note, this is a submenu, not a command) - it explicitly (even
is rather verbosely) names what's happening inside.

So if an app has no such import, all actions I see users are invoking
is Open, Save, Save As, New.

Let's do not afraid of removing for good reasons.

>> Idea of one user cannot be a measure here,
>
> Still, one user can have a good idea, as in this case. I like it, and I'm not alone.
>
>> and this command looks very new to me.
>
> Well, that's not necessarily a bad thing.
>
>> If unsure please ask our usability people for some advice
>> before so exposed change happens.
>
> But I'm not unsure.
>
>> Should you not described what "open as new" means, I swear I would not have
>> accurately guessed. Compared to Open, it just changes one state if the app.
>
> But an important one, and I'm thinking that if few people use this useful option it's because they don't really know what it does. Clarifying that would be a good thing, in my mind.
>
>> Please note it's already redundant because of that, from looking over
>> shouders of various types of users, I see they tend to use one of the
>> approaches:
>> - Open + Save As
>> - Open + Select + Copy content + New doc + Paste content.
>> More permutations of these are possible too, I'll leave that for the reader
>> :)
>
> So it's not redundant, it would save the user a lot of keystrokes if only they realized what the command did.

It does not matter how many keystrokes/mouse clicks are needed as long
as users are not lost performing them. I know the proposed replacement
will not be used more frequently. The action you propose is rarity:
it's for users who do not open existing document - instead they
directly copy the (currently unseen) document (known by name) to a new
document, and open it. It's not an atom, it's a relatively specialized
macro.

because it takes so long to even explain what the command does (please
try do that for QWhatThis...), in my 'usability imagination' the
command itself is suspicious at least.

>> There's even overlapping with functionality of templates.
>
> I disagree there, that functionality is almost completely different.

If you look around in office, existing documents are extremely often
used as templates. This means big overlap between selecting template
and the proposed action.

It's over - no chance to teach users and fight with their habits at
this level - no chance because they have zero pain with the current
workflow. They use 'save as' rather infrequently. They do not deal
with terabytes of data, they have machines capable of even handling
everything via clipboard.

But we can try to have minimal set of intuitive commands.

>> So I'd like to also ask for links to existing software having this exactly
>> action. When I asked someone about that, the only virtually similar (but
>> textually!) was "open link in new window".
>
> Well, I'm not going to provide you with that list. I think the proposal has enough merits on its own.
>
> To summarize:
>
> * we have an action that has been mislabeled for the past decade or longer
> * because of that, users don't use it -- they don't know what it does
> * we never renamed it because the current name is "traditional"
> * but if we would rename it, it would be clear what it does and improve life for our users
>
> Sounds like a win to me.

According to what you say users don't know what the current label
does. Are we able to measure ambiguity of the current label and also
the new one?

In this development, change is always bad if the 'new' is not clearly
better - to the user.

In absence of metrics, I am against of this change.
Current reasoning is not convincing:

- 'Import' is ambiguous
- 'Import' is traditional <- pejorative point made here
- 'Open As New' is clear <- How? Only declaration has been made but no
explanation of how you understand semantics of this command? e.g. how
translatable is it?

It's not a discussion if we should take any action or not. We should.
It took me a while to explain the above.

As stated above, I propose to remove the Import option for apps that
do not offer anything beyond the functionality already provided by
Open.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek