[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: K-ARTIST: MIME icons for KOffice
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2003-12-28 3:47:05
[Download RAW message or body]

Allan Sandfeld Jensen wrote:
> On Saturday 27 December 2003 23:48, James Richard Tyrer wrote:
<SNIP>
>>It is logical for a WordPerfect file to have a MIME type icon with the
>>WordPerfect application icon on it (to me that does reflect the content of
>>the file).  But, with a PostScript file, there is no application associated
>>with that MIME type and it needs to have a MIME type icon reflecting the
>>content of the file.
>>
> 
> The idea breaks down when integration comes along. It wouldnt make sense for 
> kword-documents to contain kword-art once it uses the same format as 
> openoffice.org. 

Yes, I agree with you here.  When we have a common document format, I hope that they have 
a trademark like image for it.  If not, then we will need to use content based MIME type 
icons like with PostScript files.

> If we used this concept we would need to treat work-formats 
> (tied to an application) and publishable MIME-types (tied to a standard) 
> differently. 

This wouldn't be too illogical since there are different ways of naming MIME types that 
correspond to these differences.  That is, those that have a major type: "application" 
should be treated differently than those that start with a data type (i.e. audio, text, 
video) which should probably have a content based icon.

> And even then there's a grey-zone with application-specific 
> types that have become de-facto standards (like MS Word files).
> 
This specific case has additional issues since we don't have a MS-Word application icon 
and I presume that M$ wouldn't be very pleased if we used the official one
> 
>>There is a better alternative when the data file format actually has an
>>trademark image associated with it like SVG and Acrobat.  But, others that
>>appear to be like this such as RPM and Real are just using the
>>application's icon.
>>
> 
> All the Real-formats have been changed to generic video and audio icons to be 
> able to distingues RealAudio and RealVideo.
> 
> 
>>alternatively, we could have all of the various MIME types for a generic
>>application type have the same MIME icon.
>>
>>For example: have all spreadsheets applications use the generic
>>'spreadsheet' icon for their files.  But then the MIME type icons are not
>>distinguishing between different MIME types.  I find it helpful to be able
>>to tell at a glance which spreadsheet files are for Quattro Pro and which
>>are for GNUMeric.
>>
> 
> All spreadsheet types are using the generic 'spreadsheet' icon now (except 
> Applix I think), since none of the MIME types had usefull specific icons.
> 
> 
>>You do raise a valid question, this is a usability issue.
>>
> 
> Yes, and one I have been working on. I would love it if we could reach some 
> sort of agreement. Even if it goes against what I've done so far.
> 
I would like to see different MIME types have different icons as I said about Quattro Pro 
and GNUMeric.
> 
> For KDE 3.3 or later:
> The best idea I can come up with, is to use generic base icons (spreadsheet, 
> database, etc.) and then superimpose an application onto it to create a 
> specific one (a kword file would be the wordprocessing icon with a 
> koffice-watermark). That way we can have both generic icons, and only need a 
> composition icon for each office-suite or company.

I will have to leave that to the actual artists to make those.  It was brought up that we 
didn't have MIME icons for KOffice, and I can make the ones I am working on (if I survive 
the cold I got for Christmas :-)).  I think that we agree that these MIME types should 
have icons and if we come up with something different later (for 3.3), it is OK.

--
JRT

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]