On 15 August 2012 15:13, Boudewijn Rempt <b...@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
