On Fri, Sep 10, 2010 at 13:23, Patrick Ohly <[email protected]> wrote: > On Thu, 2010-09-09 at 11:50 +0100, Patrick Ohly wrote: >> On Wed, 2010-09-08 at 20:25 +0100, Alexander Bokovoy wrote: >> > On Wed, Sep 8, 2010 at 21:29, Auke Kok <[email protected]> wrote: >> > > Do we need bugs against handset components for not providing the proper >> > > "MimeType=..." fields in the respective handset app's .desktop files? >> > Yes, we do need that. See libcontentaction for details. >> >> Ah, great! That was what I was looking for. Thanks for the pointer. > > After thinking about this some more, I'm still wondering whether a truly > generic Tracker search + visualization + action implementation is > possible. > > For a simple kind of visualization, yes, this probably works: > 1. show uri (not localized, very technical) > 2. pass uri to Action class to get list of available actions > 3. show ContentAction::Action's localized name and icon (both from > the .desktop file) > > But step 1 is clearly not sufficient. What would be needed instead is > some class specific formatter which extracts further information and > displays that. For example, a contact might be displayed with photo and > full name. So far this is part of application-specific resource usage and user experience design for that application. For example, a hypothetical file manager might want to expose broken apart nfo:fileUrl while image viewer would use thumbnail and image description (coming from EXIF or XMP) instead, not showing the name of resource at all.
> I was wondering whether there were "generic" RDF triplets that would > help (like "display name" or "thumbnail", set for anything which has > something remotely resembling such properties), but that doesn't seem to > be the case. > > Is there perhaps a libcontentvisualizer or libcontentsummarizer (mapping > to some common properties, like thumbnail and text)? I doubt it because > this is so design specific, but as always, better ask than be sorry ;-) Exactly, it is too specific to application problem domain and UI design concept so that making it generic would probably not work well. Add to that l10n support and you'll get into real trouble even with moderately rigid set of 15 languages in N900. > Regarding step 3, there's a similar issue. Suppose there is a contact > with several email addresses and an action for email addresses described > as "send email". It would be nice to show this as: > Aaron Alewife > send email to work address ([email protected]) > send private email ([email protected]) > > Instead one can only concatenate: > Aaron Alewife > work address ([email protected]): send email > private address ([email protected]): send email This is again question of representing actions: do you start from the subject or object, do you want to play around the language forest by using graphical concepts instead of the text and reverting to the textual representation only for the parts that absolutely require it (email address, for example). Each decision made limits the number of choices and actually becomes part of the UX definition. For example, http://meego.com/developers/ui-design-guidelines/handset/designing-your-application recommends drill down style which implies repeatedly shortening context choices. If you are after the action rather than the tool (I want to send a message to Aaron rather than I want to use Aaron's email), this moves you through the context by eliminating extensive information -- after you decided about sending an email, no need to repeat this information again, concentrate on sending email options. This breaks down need for linguistically perfect statements, for example, and allows to get away without libcontentvisualizer or libcontentsummarizer. This is just an example, not a rule, though. > The part before the colon would have to be generated by some domain > specific code. > > Because the "send email" part is provided by MeeGo apps without > necessarily knowing in which context the text will be used, should we > establish some MeeGo guidelines? > > For example: > * reasonably short (40 characters) > * no complete sentence > * therefore capitalization as in the middle of a sentence ("send > email" instead of "Send email") I would rather go through the existing UI guidlines and look at what style of communication it tries to promote, then design action summarization guidelines around those. -- / Alexander Bokovoy _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
