So my idea is to use the new /music scripts as the basis for all the media management on the site. Right now that means updating /image to the new format, and also creating /video. Basically all the heavy work is done, I just have to tweak the script to look in different tables in the database (say, the image table instead of music) and then change how the output is displayed.
First, does anybody see any big problems I am missing?
And next, what information do people want displayed in /image? Obviously the description of the picture (this will be like trackname is in /music.) Do we want the filename displayed to, or just link the description to the filename like /music does it? Of course the size of the image file. Maybe the upload date? Do we need to see the image owner listed?
I'd like to keep it as simple as possible. Additional information for each picture could be displayed (as it is now) on the image edit screen. But what info can't be left off the main /image lists?
I don't feel I need a lot of info on images: file type, size, owner, id(name). I am nervous about my own eager anticipation of posting quicktime video. This is an ignorant question, but should we be concerned for storage space? Even if that is a non-issue, putting video on the tree feels like a guilty pleasure... and possibly opening a can of worms. I dunno what those worms look like, but my spidey sense tells me they might overcome us. Should I just chill and excercise self-control (yes that option is within the realms of possibility) ... or should we reconsider whether we even want the video option?
No, we're going to have video. But yes there are concerns. Tom and I touched on this yesterday. I don't want to get into the full discussion yet, but in the short term storage space is a problem. We only have 2.5 gigs of space left, so obviously we will burn through that quickly if we are posting music and especially video.
Bandwidth will be another issue, but that one is a little further over the horizon.
I'll have more to say about storage soon. I'm still getting all my facts together.
1. Re the image files: I think the system is great as it is now. I'm guessing you want the new script applied to it so everything's consistent, but I don't think I need any more or less information than what's there now. The music script serves a particular purpose: to have a searchable, categorizable, sharable database of all of our music, whereas the image files are more personal to each user. They don't need to be as "poolable" as the music files. I think grouping them alphabetically by folder, and reverse chronologically by upload date, as they are now, works great. I ike seeing the filename next to the description, again, because I "work" with the image files a lot more than music files (reload, repost, refer back). I wouldn't change it from where it is now, but that's me.
2. The issue Sally raises is what you've called "the conversation" and I don't think it would hurt to start having it. Having upload capability for images, music, and video is like offering crack to certain personality types (speaking for myself here). Do I use a little crack, or do I have limits imposed on me that I agree to? That's how I would start the discussion. (We don't have to do this publicly.)
Well, the biggest thing the new front end has is the ability to page forward and back through the info (previous and next links.) The present /image system can't do that. So I think the present system will not be workable into the future. I don't want to load my complete list and have it be 10,000 pictures long, all listed on one page!
And yes, I agree we probably don't need to be able to add other people's pictures to our albums, but this functionality is already present in the image system as it is now. The new system doesn't add any features expect 'previous next' links and searchability. The changes are really mostly in the user interface.
But it may be that it is not a good UI for pictures.
Good point about the complete list--I forgot about that. Mine's unmanageable as it is now, and heaven help anyone who thumbnail views it. Adding searchability is great, too.
Maybe it's ugly though? It's hard for me to decide. I'm too close to it.
It does look a little like a windows app to me, which makes me suspicious that it actually is ugly. Also it might be my first use of colors which is also making me nervous.
On the other hand, I think this top level /image page is ugly right now. And worse, it doesn't really tell you as much as it might. While I like things to be as simple looking as possible, I think this might be too simple.
But maybe /music is too complex.
UI design is a different art than coding.
Form follows function. If it works, and gets you where you need to go, it's beautiful. The music page uses color to the extent necessary to differentiate different functions, and gets a lot of info on the page (it all fits on my 800 X 600 15" screen). If you put the same info that's currently in the image database in that format it should be fine. I assume "playlists" would be "albums"--but would the reverse chronology be lost in favor of alphabetical? (I'm thinking, too, of the issue we discussed of numbering items in playlists.)
I agree that chronological is very important for images (but not really for music.) I guess we'd want it to default to reverse chronological and then have the description be clickable in the column head to have it sort alphabetically, like you can click 'artist' and 'album' in the /music column head. (And yeah, I'm still going to change the music default to sort by album instead of trackname like you suggested.)
Probably we want the image date visible? Name, size, and date seem like the crucial bits. Maybe filetype too.
So the table for each list (complete list, album list) would have the following columns:
id# / filename / size / description / date / filetype That seems good, as long as it's not too much for one row.
I don't think we need both filetype and filename, since the filetype is at the end of the filename. But maybe we don't need filename, in the same way we don't have it in /music except in the sense that you can mouse over the description and see the URL which is the filename.
My sense is that filename is more important in /image than it is in /music though.
So either:
id# / description / size / date / filetype (where description links to the actual file)
or:
id# / filename / size / description / date
And of course, either one could be too long depending on how long people make their descriptions (and/or filenames.) The first one has a better shot at being compact though.
I'd say
id# / filename / size / description / date I'd forgotten that the filename includes the filetype. I think it is important with images to see both the filename and the description, since the filename is used as the main identifier in tags that are frequently changed (at least by me), and the description becomes the alt tag.
But if date is used for reverse chronological sorting, won't there be a problem with all existing images in complete list being undated? Right now they're in there in the reverse order in which they were uploaded--no dates were assigned except to the folders.
You are right about the need for filename and description. So that's solved, we'll go with:
id# / filename / size / description / date
All photos have an upload date (not necessarily when the picture was taken, true.) It's possible that info was never displayed before, but it's in there.
Oh--and I don't think the interface(s) are ugly. They look good to me. They don't make me think of Microsoft apps, which usually have a lot of wasted space and extra buttons for stuff people don't need.
|
First, does anybody see any big problems I am missing?
And next, what information do people want displayed in /image? Obviously the description of the picture (this will be like trackname is in /music.) Do we want the filename displayed to, or just link the description to the filename like /music does it? Of course the size of the image file. Maybe the upload date? Do we need to see the image owner listed?
I'd like to keep it as simple as possible. Additional information for each picture could be displayed (as it is now) on the image edit screen. But what info can't be left off the main /image lists?
- jim 3-26-2004 7:33 pm
I don't feel I need a lot of info on images: file type, size, owner, id(name). I am nervous about my own eager anticipation of posting quicktime video. This is an ignorant question, but should we be concerned for storage space? Even if that is a non-issue, putting video on the tree feels like a guilty pleasure... and possibly opening a can of worms. I dunno what those worms look like, but my spidey sense tells me they might overcome us. Should I just chill and excercise self-control (yes that option is within the realms of possibility) ... or should we reconsider whether we even want the video option?
- sally mckay 3-26-2004 7:42 pm [add a comment]
No, we're going to have video. But yes there are concerns. Tom and I touched on this yesterday. I don't want to get into the full discussion yet, but in the short term storage space is a problem. We only have 2.5 gigs of space left, so obviously we will burn through that quickly if we are posting music and especially video.
Bandwidth will be another issue, but that one is a little further over the horizon.
I'll have more to say about storage soon. I'm still getting all my facts together.
- jim 3-26-2004 8:05 pm [add a comment]
1. Re the image files: I think the system is great as it is now. I'm guessing you want the new script applied to it so everything's consistent, but I don't think I need any more or less information than what's there now. The music script serves a particular purpose: to have a searchable, categorizable, sharable database of all of our music, whereas the image files are more personal to each user. They don't need to be as "poolable" as the music files. I think grouping them alphabetically by folder, and reverse chronologically by upload date, as they are now, works great. I ike seeing the filename next to the description, again, because I "work" with the image files a lot more than music files (reload, repost, refer back). I wouldn't change it from where it is now, but that's me.
2. The issue Sally raises is what you've called "the conversation" and I don't think it would hurt to start having it. Having upload capability for images, music, and video is like offering crack to certain personality types (speaking for myself here). Do I use a little crack, or do I have limits imposed on me that I agree to? That's how I would start the discussion. (We don't have to do this publicly.)
- tom moody 3-26-2004 8:13 pm [add a comment]
Well, the biggest thing the new front end has is the ability to page forward and back through the info (previous and next links.) The present /image system can't do that. So I think the present system will not be workable into the future. I don't want to load my complete list and have it be 10,000 pictures long, all listed on one page!
And yes, I agree we probably don't need to be able to add other people's pictures to our albums, but this functionality is already present in the image system as it is now. The new system doesn't add any features expect 'previous next' links and searchability. The changes are really mostly in the user interface.
But it may be that it is not a good UI for pictures.
- jim 3-26-2004 8:39 pm [add a comment]
Good point about the complete list--I forgot about that. Mine's unmanageable as it is now, and heaven help anyone who thumbnail views it. Adding searchability is great, too.
- tom moody 3-26-2004 8:42 pm [add a comment]
Maybe it's ugly though? It's hard for me to decide. I'm too close to it.
It does look a little like a windows app to me, which makes me suspicious that it actually is ugly. Also it might be my first use of colors which is also making me nervous.
On the other hand, I think this top level /image page is ugly right now. And worse, it doesn't really tell you as much as it might. While I like things to be as simple looking as possible, I think this might be too simple.
But maybe /music is too complex.
UI design is a different art than coding.
- jim 3-26-2004 8:47 pm [add a comment]
Form follows function. If it works, and gets you where you need to go, it's beautiful. The music page uses color to the extent necessary to differentiate different functions, and gets a lot of info on the page (it all fits on my 800 X 600 15" screen). If you put the same info that's currently in the image database in that format it should be fine. I assume "playlists" would be "albums"--but would the reverse chronology be lost in favor of alphabetical? (I'm thinking, too, of the issue we discussed of numbering items in playlists.)
- tom moody 3-26-2004 9:02 pm [add a comment]
I agree that chronological is very important for images (but not really for music.) I guess we'd want it to default to reverse chronological and then have the description be clickable in the column head to have it sort alphabetically, like you can click 'artist' and 'album' in the /music column head. (And yeah, I'm still going to change the music default to sort by album instead of trackname like you suggested.)
Probably we want the image date visible? Name, size, and date seem like the crucial bits. Maybe filetype too.
- jim 3-26-2004 9:41 pm [add a comment]
So the table for each list (complete list, album list) would have the following columns:
id# / filename / size / description / date / filetype
That seems good, as long as it's not too much for one row.
- tom moody 3-26-2004 9:58 pm [add a comment]
I don't think we need both filetype and filename, since the filetype is at the end of the filename. But maybe we don't need filename, in the same way we don't have it in /music except in the sense that you can mouse over the description and see the URL which is the filename.
My sense is that filename is more important in /image than it is in /music though.
So either:
id# / description / size / date / filetype (where description links to the actual file)
or:
id# / filename / size / description / date
And of course, either one could be too long depending on how long people make their descriptions (and/or filenames.) The first one has a better shot at being compact though.
- jim 3-26-2004 10:42 pm [add a comment]
I'd say
id# / filename / size / description / date
I'd forgotten that the filename includes the filetype. I think it is important with images to see both the filename and the description, since the filename is used as the main identifier in tags that are frequently changed (at least by me), and the description becomes the alt tag.
- tom moody 3-26-2004 10:49 pm [add a comment]
But if date is used for reverse chronological sorting, won't there be a problem with all existing images in complete list being undated? Right now they're in there in the reverse order in which they were uploaded--no dates were assigned except to the folders.
- tom moody 3-26-2004 10:51 pm [add a comment]
You are right about the need for filename and description. So that's solved, we'll go with:
id# / filename / size / description / date
All photos have an upload date (not necessarily when the picture was taken, true.) It's possible that info was never displayed before, but it's in there.
- jim 3-26-2004 11:06 pm [add a comment]
Oh--and I don't think the interface(s) are ugly. They look good to me. They don't make me think of Microsoft apps, which usually have a lot of wasted space and extra buttons for stuff people don't need.
- tom moody 3-27-2004 1:15 am [add a comment]