Monday, February 06, 2012

And One More Desktop Change

This is really a small change, but thought I'd publish it in case it's useful to anyone else for deployments. Users really, really struggle with three areas: File types, File Size and Folder Locations. I've blogged many times about steps taken to make interaction with files simple and not require file managers. Now that the major technology pieces are finished for us to go live, I can get back into some ideas that have been in my head. I had development something like this for use with our USB sticks on the thin clients, and brought it over to the GNOME desktop. When you double-click on an image now, it allows you to change the size before it's placed into the clipboard. They can shoot in 10megapixel all they want, and with a single click make it "email friendly" for delivery. Having people go into GIMP and reduce and then copy and paste is just way too many steps.

In the shot below the tux picture is double-clicked and the MIME helper bar appears. By selecting "OriginalSize" the image is then pasted into Evolution at 1024x768. This is the default.

However, if if they want to copy it 320x240, all they do is select the ComboBox setting and then put it into the clipboard and python reduces it automatically and then it goes right into Evolution.

It's nice to have some time to make these changes, perhaps it's the calm before the storm :)


Dave Richards said...

PS: The popup about possible load problems. This was because users were cranking a bunch of Flash content and chewing CPUs. This is part of the portal alerts me at certain thresholds.

Jan said...

The implementation sucks.

People have no idea what 320x240 is, they have no idea what their screen resolution is nor what a good size for an email attachment is.

It needs to be done automatically. You copy something and when you paste, the Application determines whether it is a good idea to resize/compress. Much better.

Joseph Wenninger said...

I think "The implementation sucks." as a first line in a comment is a little bit rude.

That aside, I don't think it can be done automatically.

The e-mail app cannot know if I want to send somebody a scaled done version for screen usage or a high quality version for printing. Neither can most other apps do that.

Perhaps instead or additionally to the size in pixels a choice of the file size in mega bytes / kilo bytes (like the iPhone mail (photo) app does, would be nice. They have the options (retranslated from german): original size (x.y MB), large (xyz KB), medium (xyz KB) small (XY,Z KB)

Anonymous said...


Should the file size at the bottom ("86 K (Small)") have changed when you chose to resize? (Also, nice idea to provide interpretations of sizes.)

Do the target sizes for images preserve aspect ratio? People rarely want their image squished or stretched to exactly match 4:3.

Does "Deliver with Evolution Bypass" do what it sounds like (directly send an email without using evolution)? Does it exist for convenience or to work around a bug?

Right now, you have the resizing dropdown near "Save", and the "Email Friendly Size" near "Email"; you might want to combine those somehow.

(Also, that should say "Email-friendly", not "Email Friendly".)

More generally, you might consider dropping a note to the GNOME UX people, who could probably help you streamline the design of that dialog while preserving its functionality. Among other things, I suspect you want to take advantage of more horizontal space to unpack the options a bit, add some icons for fast identification and clicking, visually associate the resize dropdown with several different items, and change from specific sizes to descriptions like "Original Size", "Web/Email", and "Thumbnail" (along with "Custom" for the unusual case of wanting a specific target resolution). When dropping a note, mention your standard screen size, so they don't need to worry about smaller sizes as they normally do.

Dave Richards said...

@Jan: I don't have any control over GIMP, Evolution or OpenOffice to change how they work. I agree they should have a way to sanely accept a paste.

@Joseph: Right, I had thought of using words to describe the sizes similar to how it's done on the iPhone. It's always proven hard to find the language to communicate with users.

@Anonymous: Changing the bottom message is interesting, it was reflecting the size of the original image; and once they place in the clipboard this dialog closes after it's been pasted. The target sizes resize on one of the other sides, so it's not distorting aspect ration. Evolution bypass uses a small perl routine to deliver right to SMTP and not go into their email. The reason for this is because of quotas. Very often they don't care if they have a copy in their SentItems. It just goes right out, regardless of file size. My Glade skills have gotten better since I built this UI and it does indeed need some language and icon changes. I kind of post things that I had to interject into GNOME to give the developers ideas for future releases. Files are just a constant struggle for users.

Anonymous said...

I have no idea how to help people that have no idea about desktop resolutions or image sizes, but I for one love this feature as right now I always end up manually resizing my images for use in Evolution mails.

Evolution makes this process even more of a pain in the back as it does not reload an altered picture if you didn't also change the filename before inserting in the second time.


Anonymous said...

If it would be just for emailing, what if this would be done by the email application itself?

Example, user drags file to new email, it gets added as attachment.

That is easy, right?

So, how about when the attachment box would have a dropbox to do something for a file, like "downscale to 800x600"?
And if the image is inline attachment, then have a drag position from to drag in live a image to smaller size.

And after the email is modified as it is wanted to be, save as draft or sending saves it as it looks or is configured. No need to go file by file to copy-paste or edit anything else.

File should be file no matter where it is and it should not be modified unless user wants to especially modify that file.

The old Unix philosophy is great "Everything is a file". Where user should just direct or move files from A to B and then do something it in settings.

But your idea gives possibility to copy picture to new file without first going trough image editor. But now if looking the way it is done on word processors, you just drag and drop image, scale it visually and let it be.