Version: unspecified (using KDE 4.7.4) OS: Linux Currently the filenames of connected resources in the Activity Screen are truncated so radically that at least with my files I can hardly - or not at all - tell them apart. This definitely affects the academic context because journal papers usually have year and author names at the beginning, but it would also affect business users whose companies have file naming policies that put e.g. the date at the beginning of the filenames. Reproducible: Always Steps to Reproduce: Connect two files to an activity with identical or similar beginning of names. Actual Results: You can hardly - if at all - tell your files apart because you only see the identical or similar part Expected Results: a) Filenames expand over two lines or b) Names are truncated in the middle
This might be a more general issue. In the Application Launcher for example, titles are truncated. In a mouse/context menu world, longer names can be made visible. With touch, there's no way to display the app name except for launching it.
Yes, thats a bigger issue in my opinion as well. I had in the beginning some wireframes where single touch on a resource showed a more details description of the metadata and the full name of the resource. also different options from the context menu has been shown (with open as the first option). We dumped that idea because of the longer interaction principle for opening resources (tap once to open details, tap two to open file). Well, on the desktop there are several visual possibilities, one is the icon view (which we have now), another one would be showing a list of items with fullname and metadata like date/type/size etc. I guess on the long run we need to improve the display and filtering methods for the activity screen anyway. If one activitiy contains about 100 resources, how can the user ever find the one he needs? Or we integrate a really good search feature, that works either on the selected activity or on the complete system. So, of course we can improve short term with the proposals Thomas mentioned. On the long run I guess we need to rethink a bit more on this topic. A very elegant solution came up in a little sketchboard workshop I ran here in the company before christmas: one participant presented an interaction principle with a short swipe on the resource icon to the bottom, to reveal most important details and menu options (like name, date, "open" etc). With another longer swipe to the bottom he could enlarge this menu and show the SLC specific options, like "mail to" or "duplicate".
I like the concept of little the swipe over to reveal more details... however at the moment moving horizontally the finger over an icon scrolls the icons view, moving vertically scrolls the whole screen.. The vertical scrolling can be blocked in order to make this, but then becomes very difficult to scroll.
(In reply to comment #3) > I like the concept of little the swipe over to reveal more details... +1 Swipe seems much easier to me than hold > however at the moment moving horizontally the finger over an icon scrolls the > icons view, moving vertically scrolls the whole screen.. > The vertical scrolling can be blocked in order to make this, but then becomes > very difficult to scroll. True, but then I'd vote for using a different way to scroll the screen, because we currently have the same problem with Plasmoids anyway (see bug 283171 ). We cannot just prevent Plasmoids form using vertical swipe, so it makes more sense to me to have a different method to scroll the screen and allow vertical swipe for Plasmoids and resources. Another argument for this is that having activities that need scrolling isn't such a common case (plus, the scrolling isn't so great in general because you have to remember that the resource you are looking for is somewhere below the viewport before scrolling).
hmm, in the beginning we discussed some other interaction ways here as well: one has been zooming interfaces (hehe, I hear Marco scream), with for example 3 different states: - one: fully zoomed out, showing all boxes. - two: zoomed in to see about two lines of boxes (like current activity screen) - three: zoomed into one box to display all resources of that box in a grid, perfectly adapted to the screensize But I must admit that in case three there could be that many resources that we need some scrolling here as well.
yeah, still have kinda same opinion about zooming ;) (adds level of complexity in code and ui, still thinking pinch maps better to resize of a single box) about scrolling of the view, yes it's annoying, and yes probably would work a bit better with vertical scrolling in boxes/plasmoids, horizontal scrolling of the whole view. it would of course be still not perfect, tough having to zoom out and zoom in to scroll would also be a bit strange
*** Bug 296940 has been marked as a duplicate of this bug. ***
Problem has been slightly reduced as the displayed file names seem a bit longer by now, but it's still present.