Thanks Brynn and Máirín, glad to see this necessary discussion continuing. Máirín, I'll reiterate the thanks others have already given for attending to the UX design here; what you proposed is along the lines of an earlier sketch I'd made myself, and am liking the direction things have been going.
Mc was dutiful enough in getting a preliminary patch prepared to implement the new dialog design and proposed it in time for 0.92.1's cutoff. I've actually delayed a bit in hopes of getting the patch included, but my gut told me it needed a bit more polish, and the ongoing discussion here is reinforcing that feeling. Alas, given the tight schedule I've set for ourselves, I think we'll need to push this to 0.92.2. Fortunately, there's no need for a particularly lengthy development period for 0.92.2, so we can time it to suit what's needed for perfecting this patch. And the existing dialog's text is at least familiar, so at least shipping it in .1 won't create any new confusion that wasn't already there. :-)
I definitely like the new wording, but I agree with Brynn's assessment that on first view the dialog's more info section doesn't clearly match up to the provided options, and that aspect could stand improvement. So, I'd like to see more UX attention on ensuring the relationship between the core options and the explanatory text is extremely clear.
Another aspect I worry about is translation. Even in english this is a complex dialog with careful phrasing needed to communicate the intent; I imagine the wording challenge will be repeated for each language it's translated into. However, since this dialog is going to pop up for all legacy documents, it's going to be popping up a LOT, and so it'll be important that each language has time to optimize the wording.
For all these reasons, I think it's important to make doubly sure we make the English version's text extremely concise and as straightforward as we can make it. In particular keep in mind some languages like German tend to use lengthier words, which can make dialog sizing an issue. So, the fewer words the better.
[I'm CCing Amelia in regards to the above, since she professes a talent at minimizing word count, that so many of us (me especially!) lack...]
Regarding visuals, I concur with everyone else as to their value. And if any project should be able to craft good visuals it's us! Hopefully delaying this patch to 0.92.2 ensures time to craft high quality graphics. The one major limitation I would suggest is that we need to make sure the physical 2D area required of the dialog does not exceed what's available from our minimum supported monitor dimension (e.g. something like 800x600); perhaps the dialog code can conditionalize display of icons based on the available real estate, or else the verbage can be reduced in word count to permit room for the icons. As a secondary limitation, while pushing this to 0.92.2 gives us ample flexibility, if coding support for the icons (including allowing clicking on them to select the option) incurs too much additional code review work, that could potentially impact the release schedule.
Thanks again, Bryce
On Wed, Feb 01, 2017 at 07:20:31PM -0500, Máirín Duffy wrote:
Hi Brynn!
Thanks for the feedback! More below -
On 01/27/2017 08:34 AM, brynn wrote:
Sorry I missed this whole discussion yesterday. But I wanted to say that I like jabier's idea with a small graphic to represent what each option does, which clicking on it also sets the option choice.
I agree that visuals are a good idea - they don't require as much time to grok. I can draft up icons for this. If anyone has ideas on how to represent let me know. My initial thoughts (feel free to come up with better ones or just let me know if any of these wouldn't do):
- Digital art option: a paintbrush painting an image on a laptop screen
- Appearance option: a graphic with a lot of shiny and effects /
sparkles on it
- Size accuracy option: artwork coming out of a printer with a ruler
lined up with it
For the last version of the mockup I saw: I agree with whoever mentioned about "Choose if unsure". A lot of newbies, as well as not newbie, but still not very techically aware users, will choose it, simply because they don't understand it. So I'm not sure if "choose if unsure" should be there at all. I think the text, and maybe a small graphic, as jabier suggestion, should be clear enough that most users will be sure what to choose.
I completely understand your rationale, and it is logical. I can also say consistently based on my experience as a UX designer - having conducted many usability tests and read quite a bit of research - that the majority of users will just not read the explanatory text.
It's not that they are stupid or don't care. Their goal / focus is simply elsewhere and they don't want to have to make a decision like this - they fear them. I think it is a good practice to have a very obvious "choose this if you dont know" option, because at the very least, it is the least destructive option of any of the 3 we have to offer, it does the least amount of change to the file, and if it ended up being the wrong decision, they can manually adjust the file (I'm assuming!) later on.
I'm not saying that the tactic of having a default choice is absolutely the right one in this scenario - we can take a look at how the screen design reads with the icons, for instance, and see if it makes it clearer which option to choose - but I'm just saying with a lot of experience with this sort of problem (diff context but same problem, think storage and system management UI... ) having a 'default' is the option that users are best able to navigate and requires less cognitive load.
The tension here is the users having to learn something when they're not necessarily in the mood / have the time to learn vs. us taking on the guilt of pushing them towards something that might not be the perfect decision for them and could impact their files negatively. I do think if they choose the default option we push here, that the negative impact isn't going to be significantly high (they print it, it doesn't fit the page correctly, they adjust manually. Costs them a piece of paper, some ink, and time. Ok, so that print could be a plotter print, but still :) )
Where it says in the More section, 'there are 2 scaling methods - the whole document, or the individual elements in a document' - that is very clear to me. But which goes with which option above? I'm guessing they describe the 2 sub-options for the 2nd main option?
To more clearly link them, we could use the same text in the top UI options and in the bottom explanatory text. Since I think framing in terms of the user's context is more important, I would use the text that talks about the type of artwork. Maybe instead of italicizing it, bolding it:
- Appearance
- Accuracy of Scale
So where the bottom talks about each method, the bold text titling that section would say Appearance / Accuracy of scale and then after that explain for appearance, we scale the whole document.... so on and so forth.
Because of all the info provided in the More section, I'm not sure what info is going to be included in the FAQ. It seems like the More section should be in the FAQ, and at the bottom of the dialog, it should be a link to the http anchor for that item.
I agree. That is a better way to do it. We could use the same text and even have a screenshot of the dialog in the FAQ if need be.
If more technical info (than what's in the More section) is going to be available, maybe it should go in the developer faq, in the wiki. Then the user faq item (on the website) could link to it in the wiki.
As one of those 'not newbie, but not very technically aware' people, the first 2 main choices are very clear to me (screen display or printer). But I'm still a little unclear for the 2 sub-options for the 2nd ("physical output") main option.
Does the 1st sub-option mean if my drawing has any clips, masks, filters or clones, I should choose that option? Because if the 2nd option (accuracy of physical unit/position) means 'is the file going to be used for 3d printing', such a file is probably not going to have clips, masks, filters or clones.
If your drawing is meant for printing *and* it has clips/mask/filters/clones/etc., yep, that's the option for you.
So I wonder if it could be simplied to a) The image contains clips, masks, filters or clones b) The file will be used for 3d printing
The one worry I have here is if you're printing the file out, are worried about scale, but the artwork doesn't have clips, masks, filters, or clones. You still probably would want that option.
I wonder where files used for cutters/plotters would fit - all the new gcodetools and etc.? I guess they would choose the 2nd option? If so, then maybe the 2nd option should be b) This file will be used with 'digital'? 'computerized'? cutters/plotters or 3d printing.
Good question - not sure.
Are these changes reversible? If not, maybe the option to make a backup could indicate they aren't reversible?
Not reliably for the 3D printer one, so a backup should be default for that option.
Could there be a "do nothing" option? Or is a choice needed for every file? If a "do nothing" option is added, it should maybe warn about the consquences. "This or that might happen" (or "will happen") if you don't make a choice.
The first option (digital artwork) is the do nothing option, which is why it's also being pushed heavily as the default choice.
I really like your idea to emphasize consequences though because I think users really care about that above all. Let me noodle on that for the text.
Last comment. There needs to be a space in "Thismethod" in the "Scaling individual elements....." section in the More section.
+1 Good catch.
Thanks for your good work Mairin, and offer to help! It's clear you have awesome skills for UX and mockups! For the most part, I think Inkscape's interface is very good. But there is plenty of room for tweaking and polishing.
Thank you - what a nice thing to say. :) I love Inkscape's interface and basically live in it. I agree there is room for tweaking and polishing, and I'm happy to help with that on the UX design front.
(This is probably a different subject, but there was recently some discussion about making the Page tab of the Document Properties dialog better - maybe split into 2 tabs, I'm not sure. Currently I have to dock that dialog to be able to see the last 3 options on that tab. This is a basic 15 inch laptop, which is apparently considered a small screen.)
I have the same issue with my laptop! I would be glad to play around with that design next.
I will have an updated mockup soon, hopefully I'll have time later tonight.
~m
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel