I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"?
I frequently hear front-end developer peers arguing that it's "painful" to read 10 or 20 lines of XML. Back-end peers retort that it's more "painful" to look at large complex structures in JSON.
There's a hundred other cases in which this comes up. Are people really walking around in crippling pain, due to various software having trivial differences from their ideal preference?
>> I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"?
One can also make that statement to the person who decided the default save format should be different from the one the user opened. IMHO most people want to save in the format they started with and if they want to change it, something other than "save" is warranted.
This isn't just a problem with Gimp. It's a problem with Photoshop and basically every discipline where there's a bunch of file formats that have varying levels of support for features.
"Open" would then more correctly called "Import" for most file formats. If you want Open and Save to work with all file formats, you'd then need to restrict the UI to operations that work with the file format you have open. Otherwise, you lose data when saving.
>> IMHO most people want to save in the format they started with and if they want to change it, something other than "save" is warranted.
Most people when they save a file expect everything to be there when they open it later. That's only possible when you save using that applications proprietary file format.
If I open a PNG in Photoshop, crop it or resize it, it stays in PNG when I save it. This is such a common workflow that it makes me wonder if you use Photoshop.
I understand your points, but it doesn't mean that there aren't pragmatic UX choices to be made here.
This. It is far too common for applications to default to saving their own .special format, despite opening another fully supported format. Save should always default to file type opened, and .special format when a new file was created. Save As is an easy and friendly enough vector for allowing saving that opened .whatever file as a .special when specifically wanted. It really is unfriendly increased mental load to open a .whatever and have to remember or figure out you must Export to retain your file type.
> I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"?
The main problem I have with it IS the fact that you have to use the mouse. There's no keyboard shortcut (at least on Mac version of Gimp). If you open a .png file, there's no keyboard shortcut to export it (overwrite). You can invoke the "export as" dialog which requires a couple more key presses and a context switch. Once you save it via menu, then the Command+E shortcut starts working, but for the first save not. As someone who works a lot with Gimp, this is the main usability problem I have.
If I open a .png, and done things to it, and I want to save it, it's because I just want to save a .png. If I wanted to have another format I would "import" the .png, not open it.
If I want to save something else, then I'll go to the save as... And will choose what I want to save.
Having a "save as..." that just gives me the proprietary format and hanging to go to the "export as..." to have other formats is even worst.
> I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"?
I found it mildly annoying at first but then I learnt that the luckily export function has a keyboard shortcut. I can accept that I have to press ctrl+shift+e to export an image ;)
XML IS actually more painful than JSON: There's more syntax, and it looks less distinct, especially if it's not properly indented. JSON look a lot cleaner, and the extra metadata that XML provides is rarely needed for casual reading.
Possibly, the more clicking needed to achieve a task does put more strain on your hands which can cause pain. I believe this is why for example VI key bindings are designed to reduce the distance your hands must extend for most common tasks. Reading extra text, XML or JSON can also cause additional eye strain... I think that is why it's okay to describe UX in terms of less or more pain...
No it's not the same amount of clicking. From Gimp 2.7 to 2.8 something that used to be ctrl-s and close window went to ctrl-shift-e, and answering four dialog boxes before getting the image saved and the window closed. Around the time Gimp 2.8 came out, I wanted to edit and save around 50 images (in away that wasn't easy to automate). That (without the plugin that gives the old behavior) would be 200 dialog boxes to deal with that I didn't have to before.
No it wasn't literally painful. But frustrating. Nearly as frustrating as people not accepting that people legitimately use software in different ways.
> I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"?
Anecdotally, this would often just outright segfault GIMP for me. I ended up having to use a different image editing program entirely until this was fixed.
I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"?
I frequently hear front-end developer peers arguing that it's "painful" to read 10 or 20 lines of XML. Back-end peers retort that it's more "painful" to look at large complex structures in JSON.
There's a hundred other cases in which this comes up. Are people really walking around in crippling pain, due to various software having trivial differences from their ideal preference?