Media Manager Sketch
Michael Heilemann
A quick quick quick walkthrough of what I like to call a 'feature-rich environment':
1) You can filter, sort and search your media library.
2) Uploading takes place in the same area, I'm working on that stuff now.
3) It is 100% of the browser width to give you more space.
4) Like the textarea, you can resize the preview shelf, but grabbing the handle underneath the scrollbar.
5) Double clicking a media preview, rolls out a small editing pane next to the image where you can edit title, desc. & tags.
6) You add media to the content area by dragging and dropping.
7) There will be more stuff :)
I'll keep you updated :)
André Costa
p.s: Awesome :P
BlueSaze
Michael Heilemann
I can hear the cries of the Habari coders from here ;)
Well, all the functionality will have to be present regardless of how the design looks. And all the bling-bling, I can code myself :)
BlueSaze
On Jan 23, 4:58 pm, André Costa <ansco...@gmail.com> wrote:
matthieu
Really nice idea Mickael.
I don't know if you remeber my media mmanager whishlist but this mockup
illustrate perfectly what I've said.
Do you have a "Media Center admin page" mockup comming or do you think
it is useless ?
Can't wait for more, this is christmas :)
matthieu
saying taht alla management is on this page.
Karthik
pouring into habari everyday. In the final release i would love to see
a media manager similar to the mockup...
Btw.. when is the dev preview coming out??
chrisjdavis
And yeah, we will probably have to sacrifice a couple of developers to
get this working properly.
Andrew Krespanis
(though I'm worried Apple might sue over the similarities to iTunes
buttons!)
With this in mind, how do the Powers That Be envisage these thumbnails
will be created? If they're going to be created with GD2/imagemagick,
perhaps we could throw in the ability to crop images that have already
been uploaded?
Heck, if we're already sacrificing developers, may as well get the best
corpse-to-features ratio!
Michael Heilemann
Very nice Mr. Heilemann, very nice indeed :)
(though I'm worried Apple might sue over the similarities to iTunes
buttons!)
Yeah, I blatantly emulated those :)
With this in mind, how do the Powers That Be envisage these thumbnails
will be created? If they're going to be created with GD2/imagemagick,
perhaps we could throw in the ability to crop images that have already
been uploaded?
I'd love the ability to crop, so I'm keeping my fingers crossed.
Heck, if we're already sacrificing developers, may as well get the best
corpse-to-features ratio!
Agreed! :D
dean.j.robinson
I will sit very patiently, waiting for more :)
I was considering throwing some of my own ideas in, but I don't know
that I can top that...well not at the moment anyway.
Owen Winkler
>
> > With this in mind, how do the Powers That Be envisage these thumbnails
> > will be created? If they're going to be created with GD2/imagemagick,
> > perhaps we could throw in the ability to crop images that have already
> > been uploaded?
>
> I'd love the ability to crop, so I'm keeping my fingers crossed.
Of all of the suggested features, I think cropping is one of the
easiest. In comparison to getting the bar itself working, cropping
may be a walk in the park.
Not having seen your idea of what happens when you select a file, I
will try to persuade you toward a lightbox/thickbox implementation,
since that would present the greatest range for selecting a crop area
and also allow us to add a few text fields for alt text and whatnot.
Of course, that (as if the design itself didn't) brings forward the
issue of a javascript requirement in the admin. Will this work at all
without javascript? Or are we now mandating javascript as an admin
requirement?
I'm also curious how this design handles video and, particularly, audio.
Also, I've never been a fan of the "one big stream of media" idea -
where *all* of the images show up ordered in some way defined by the
system. I prefer to organize my media by uploading batches to my
server into their own directories. So I might, for example, have a
directory "2007/birthday" with all of my birthday photos from this
year. Being that media on my own server would not likelye have tags
upon ftp upload, how would I navigate this?
> > Heck, if we're already sacrificing developers, may as well get the best
> > corpse-to-features ratio!
>
> Agreed! :D
Eek!
Owen
Justin Moore
> Of course, that (as if the design itself didn't) brings forward the
> issue of a javascript requirement in the admin. Will this work at all
> without javascript? Or are we now mandating javascript as an admin
> requirement?
I seem to recall (but I'm too lazy to search the archives) that it was
proposed a week or two ago that requiring a modern browser supporting
JS to use the admin was not too much to ask.
--
Justin Moore
aka wantmoore
---------------------------------------
www.wantmoore.com
Michael Heilemann
Of all of the suggested features, I think cropping is one of the
easiest. In comparison to getting the bar itself working, cropping
may be a walk in the park.
/me is flaunting a big broad 'I'm not guilty' smile on his face.
Not having seen your idea of what happens when you select a file, I
will try to persuade you toward a lightbox/thickbox implementation,
since that would present the greatest range for selecting a crop area
and also allow us to add a few text fields for alt text and whatnot.
I'll be sure to mockup it all up as I see it working, but as usual everything is up for grabs.
Of course, that (as if the design itself didn't) brings forward the
issue of a javascript requirement in the admin. Will this work at all
without javascript? Or are we now mandating javascript as an admin
requirement?
I think it should work sans JS by removing the media library. The kind of media library functionality that can be done without JS is really pointless IMHO. And also I don't think it is too much to ask that people have JS enabled if they are doing 'advanced' blogging.
But that is again, my attitude.
That said, no, this couldn't be done in any way shape or form without JS, Flash or Java. Since the two latter are horrible choices, JS it is.
I'm also curious how this design handles video and, particularly, audio.
Audio would be an icon entry with a play button that lets you preview it. It can be done in a couple of ways I suppose. Video... Well that's another matter.
Also, I've never been a fan of the "one big stream of media" idea -
where *all* of the images show up ordered in some way defined by the
system. I prefer to organize my media by uploading batches to my
server into their own directories. So I might, for example, have a
directory "2007/birthday" with all of my birthday photos from this
year. Being that media on my own server would not likelye have tags
upon ftp upload, how would I navigate this?
Well, first of all, I didn't intend to entirely replace proper gallery solutions or flickr. So perhaps it shouldn't be able to 'group' items. But if it should, that could be built as well, though perhaps it should have a flickr organizr page for doing more advanced stuff like that.
Owen Winkler
> media library functionality that can be done without JS is really pointless
> IMHO. And also I don't think it is too much to ask that people have JS
> enabled if they are doing 'advanced' blogging.
I don't think this is unreasonable, but we should decide what we're
going to support to what level so that it can be documented.
> Well, first of all, I didn't intend to entirely replace proper gallery
> solutions or flickr. So perhaps it shouldn't be able to 'group' items. But
> if it should, that could be built as well, though perhaps it should have a
> flickr organizr page for doing more advanced stuff like that.
That brings up my hope for not *replacing* Gallery, but for
*integrating* nicely with a local Gallery installation. Since Gallery
provides heirarchical organization of photos, and so does your
server's file system, perhaps we should allow that kind of navigation
within that system, too.
I still would like to keep it simple. I think that the stream of media
works fine as a default and inside directories, but I would also like
a way to navigate among the directories. Think of it like categories
versus tags. Everything gets categorized into directories and tags
are optional. We have a way to get at the tags, but now we need a way
to navigate the categories.
Owen
Michael Heilemann
That said, I personally prefer the purity and simplicity of a single layer.
The problem is providing another layer of control for putting items into folders and what not.
I'll soak my brain in it later on. There might be a suave solution to it hiding in the back of my brain :P
binarymelon
not. But if they are why just include a filter.
Michael Heilemann
I'm not sure if tags were going to be a part of the media manager or
not. But if they are why just include a filter.
They are. But I don't understand what you're getting at?
Owen Winkler
> Well, for folders I guess you could just do folder 'items', that when you
> double-click them takes you down into the folder, replacing the current
> items with the folders items... Shouldn't be too hard.
That seems fine with me, but I suspect you have a better solution
tucked away in your brain waiting to be found, yet.
> That said, I personally prefer the purity and simplicity of a single layer.
And you'll have it by means of the way you organize your media. For
us crazy folder-using folk, we get what we need, too. Win-win.
> The problem is providing another layer of control for putting items into
> folders and what not.
I don't know that we need to focus on manipulating the media that
closely. It would be nice, but I'd rather that the management system
that controls the media be used for that. Habari's management of
native files shouldn't need to do this.
Owen
Marko Mihelcic
khaled Abou Alfa
I obviously like the stylised horizontal scroll bar but the arrows on either side should provide scrolling functionality as well which I think is enough even if the end user doesn't know/can't use the scroller.
Regarding the folders, maybe a second tier above the titles of the actual names of the media. I can play around with that actually and tie it in with the latest mockup I'm about to send through.
Looks awesome!
binarymelon
like all files should just be in the root and organized using tags.
Then you could have a a filter text box where you could type in tags
and it would narrow down the files.
On Jan 23, 2:06 pm, "Michael Heilemann" <heilem...@gmail.com> wrote:
> On 1/23/07, binarymelon <r...@binarymelon.com> wrote:
>
>
>
> > I'm not sure if tags were going to be a part of the media manager or
> > not. But if they are why just include a filter.They are. But I don't understand what you're getting at?
>
> Michael Heilemann wrote:
> > > Well, for folders I guess you could just do folder 'items', that when
> > you
> > > double-click them takes you down into the folder, replacing the current
> > > items with the folders items... Shouldn't be too hard.
>
> > > That said, I personally prefer the purity and simplicity of a single
> > layer.
>
> > > The problem is providing another layer of control for putting items into
> > > folders and what not.
>
> > > I'll soak my brain in it later on. There might be a suave solution to it
> > > hiding in the back of my brain :P
>
> > > On 1/23/07, Owen Winkler <epit...@gmail.com> wrote:
Owen Winkler
>
> In my opinion folders are following the path of the dodo bird. I feel
> like all files should just be in the root and organized using tags.
> Then you could have a a filter text box where you could type in tags
> and it would narrow down the files.
Which is a fine thought except that when media is uploadeded via FTP
it does not have tags and does have directory structure. Similarly,
you can organize your photos in dicrtories using other photo album
tools, which Habari should be able to deal with gracefully. It would
be unwise to overlook these legacy organization structures.
Owen
Michael Heilemann
You can tag photos just like entries, and the media library should have great tag browsing capabilities. After you've uploaded your photos, the 'scanner' traverses directories, picking up all photos. Photos located in folders are automatically tagged with the name of that folder, prefixed with 'folder:'.
So if you upload a folder called 'birthday2005', all photos in that folder will be tagged 'folder:birthday2005'.
That would solve all issues for me, personally.
Owen Winkler
> Well, it could work like this:
>
> You can tag photos just like entries, and the media library should have
> great tag browsing capabilities. After you've uploaded your photos, the
> 'scanner' traverses directories, picking up all photos. Photos located in
> folders are automatically tagged with the name of that folder, prefixed with
> 'folder:'.
>
> So if you upload a folder called 'birthday2005', all photos in that folder
> will be tagged 'folder:birthday2005'.
This sounds like it would work for a system that is under our control,
such as the local filesystem, but there are two sticky points:
1) It could be rather difficult to traverse the directory structure of
a remote system to obtain the directories. Accessing disparate
remote systems is one thing that our media management system will be
required to do.
2) If you do not know the name of the folder you want to access, you
would not know the name of the tag to enter. Perhaps this is fine if
you've just uploaded the photo and know exactly where it is, but if
you wanted to access and post a photo from even last year, and your
photos were categorized in directories on the server, you would need
to access the server via some other means to get the directory name
that you want to browse.
Having a directory paradigm in addition to tags would also serve as a
nice analog to Flickr photo groups. A directory structure of
"groups/trips" could access the photos in the "trips" group. Another
top-level directory could be added for each organization technique
that Flickr provides access to, such as "popular" or "contacts", which
would be neat for contacts with CC-licensed photos.
For that matter, tagged photos could appear under a "tags/birthday"
directory even after the tag search. Perhaps this is the way to
amalgamate the two concepts.
Owen
Michael Heilemann
1) It could be rather difficult to traverse the directory structure of
a remote system to obtain the directories. Accessing disparate
remote systems is one thing that our media management system will be
required to do.
I'm not sure I follow on this. Would my blog for instance need the ability to talk to a remote server?
Having a directory paradigm in addition to tags would also serve as a
nice analog to Flickr photo groups. A directory structure of
Well, the flickr sets are actually more like tags, in that you can have a single photo be a part of several sets.
Owen Winkler
> > a remote system to obtain the directories. Accessing disparate
> > remote systems is one thing that our media management system will be
> > required to do.
>
> I'm not sure I follow on this. Would my blog for instance need the ability
> to talk to a remote server?
Yes, that is the plan exactly. For example, Flickr. Using Flickr's
remote API, we can get a list of all your Flickr photos with a
specific tag, or photos that belong in a certan group, or even all of
the photos on Flickr that match a specific tag and fall under a
specific CC license.
Similarly, we can use the API of other systems to access remote
content on those systems. I spoke to the persident of Viddler over
the weekend, and I'm excited about using their API to access videos
stored on their service.
All of these would be pluggable, so you can build a plugin that
accesses a new service - YouTube, Hipcast, etc. - via their API, too.
Local media storage systems like a locally installed Gallery - or even
just a directory of images in a directory on your server - would be
implemented via plugin to allow integration into the display mechanism
being designed. A couple would come with Habari by default.
In addition (and this is more advanced functionality) these plugins
could provide direct upload capabilities to the services that you're
connected to. For example, the Flickr media plugin could support
uploading. You would upload to your blog, setting the photo's tags
and such, but your blog would interface with Flickr and store the
tagged photo there. The data would not be part of Habari, it would be
stored in the remote system. Any service that supported upload via
API could work this way.
> > Having a directory paradigm in addition to tags would also serve as a
> > nice analog to Flickr photo groups. A directory structure of
>
> Well, the flickr sets are actually more like tags, in that you can have a
> single photo be a part of several sets.
Sure, they're nearly identical in how they work. But the API to
access them is different, and they appear differently on Flickr, so
why have a Habari user do something like search for the tag
"group:birthdays" rather than choose from a list of groups that
includes "birthdays"? It seems to me that we should try to make this
transition smooth. It shouldn't be any harder to find Flickr photos
from inside Habari than to use Flickr itself.
Owen
Michael Heilemann
Doug Stewart
Let's abstract all this away into an OO paradigm - Habari's media
library should be treated as a single object that abstracts all such
concerns (whether my photo is on Flickr, Zooomr, a local Gallery
install, etc.). Users such as Owen who wanted to have their Gallery
install crawled for new content could use a plugin that would present
all the info in the Gallery as merely another data stream and such
concerns as "folders" should be included as metadata, accessible if
users/plugins want to access it but backgrounded if not. This would
allow Habari to blur the line between separate services in a rather
straight-forward fashion, IMHO. No longer would you need to worry
about "Where did I upload those photos?" or "Which video hosting
service did I see that Monty Python video on?" Instead, the users
could be presented with a unified interface to ALL their data and no
longer have to worry about where it resided. Just set up some
plugins, feed in your Flickr username and path to your Gallery install
and away you go!
--
-Doug
Michael Heilemann
> library should be treated as a single object that abstracts all such
> concerns (whether my photo is on Flickr, Zooomr, a local Gallery
To my ears, and maybe I'm missing something, that cause some serious
interface issues.
The interface best suited for flickr is rather different from the one
best suited for use with Youtube...
Doug Stewart
> > library should be treated as a single object that abstracts all such
> > concerns (whether my photo is on Flickr, Zooomr, a local Gallery
>
> To my ears, and maybe I'm missing something, that cause some serious
> interface issues.
>
> The interface best suited for flickr is rather different from the one
> best suited for use with Youtube...
>
>
Videos, Pictures, etc. and then pick from there. As long as the
plugins ("class YouTube extends MediaBrowser", whatever) responsible
for each site present a unified API hook for grabbing content, it
won't matter a darn thing to the admin interface.
--
-Doug
Michael Heilemann
> Videos, Pictures, etc. and then pick from there. As long as the
> plugins ("class YouTube extends MediaBrowser", whatever) responsible
But should it extend the media browser instead of creating its own?
I'm not coding wiz, so I'm genuinely asking if that would be a good
idea?
Doug Stewart
> > Videos, Pictures, etc. and then pick from there. As long as the
> > plugins ("class YouTube extends MediaBrowser", whatever) responsible
>
> But should it extend the media browser instead of creating its own?
> I'm not coding wiz, so I'm genuinely asking if that would be a good
> idea?
True. Perhaps a MediaBrowserPlugin class... Give all of them a set
of interfaces to extend so that they can be assured of sending the
same info back up to the browser without having to reimplement it on a
plugin-by-plugin basis.
--
-Doug
Michael Heilemann
khaled Abou Alfa
I'm sorry I didn't actually understand the previous paragraph Doug can you elaborate?
Doug Stewart
> The original thoughts behind the media browser were just that. Not everyone
> cares for flickr, or zooomr, or audio casts, so why bundle why make things
> slower, why add things that might not be used. Always keep things clear and
> open for additional functionality for future proofing reasons. I can see a
> certain level of convenience with having them all under one banner but I
> don't think it should be something that's built into the core.
>
> I'm sorry I didn't actually understand the previous paragraph Doug can you
> elaborate?
>
>
In object-oriented design, classes can be created as "children" of
other classes. They are said to "extend" the functionality of their
parents and, in most cases, inherit all of the class variables and
methods of their parents.*
In our case, we would most likely create a MediaBrowser class that handled
1) gaining access to metadata on media files
2) displaying the results or passing the results to another class that
would do the heavy lifting.
Child classes could be constructed for each separate media "type", be
that type "MP3", "jpg/png/gif/bmp", "Flickr", "YouTube", etc. They
would be responsible for passing the metadata MediaBrowser needed back
to an MB instance which would then execute steps 1 and 2 as above.
Does that make sense?
(*Many OO languages have the ability to "hide" certain of their
attributes from child objects. I haven't looked at PHP's spec in a
bit but I do not believe that it has the native ability to do so... I
could be very wrong.)
--
-Doug
Owen Winkler
> 1) gaining access to metadata on media files
> 2) displaying the results or passing the results to another class that
> would do the heavy lifting.
Rather, we'd extend Plugin and Implement MediaBrowser, like:
class FlickrPlugin extends Plugin implements MediaBrowser {
public function filter_get_virtual_directory($vdirname) {...}
}
But yes, like that.
> Child classes could be constructed for each separate media "type", be
> that type "MP3", "jpg/png/gif/bmp", "Flickr", "YouTube", etc. They
> would be responsible for passing the metadata MediaBrowser needed back
> to an MB instance which would then execute steps 1 and 2 as above.
In PHP you can implement more than one Interface, so you could have a
MediaBrowser Interface and a MediaOutputter Interface which could be
implmented in the same or separate classes.
> (*Many OO languages have the ability to "hide" certain of their
> attributes from child objects. I haven't looked at PHP's spec in a
> bit but I do not believe that it has the native ability to do so... I
> could be very wrong.)
Private (in this class only) vs protected (in this class and its
descendants)? Yeah, it's got that.
Owen
Doug Stewart
> > In our case, we would most likely create a MediaBrowser class that handled
> > 1) gaining access to metadata on media files
> > 2) displaying the results or passing the results to another class that
> > would do the heavy lifting.
>
> Rather, we'd extend Plugin and Implement MediaBrowser, like:
>
> class FlickrPlugin extends Plugin implements MediaBrowser {
> public function filter_get_virtual_directory($vdirname) {...}
> }
>
> But yes, like that.
>
Hadn't tooled around the code enough to know whether such a beast as
MediaBrowser exists yet.
> > Child classes could be constructed for each separate media "type", be
> > that type "MP3", "jpg/png/gif/bmp", "Flickr", "YouTube", etc. They
> > would be responsible for passing the metadata MediaBrowser needed back
> > to an MB instance which would then execute steps 1 and 2 as above.
>
> In PHP you can implement more than one Interface, so you could have a
> MediaBrowser Interface and a MediaOutputter Interface which could be
> implmented in the same or separate classes.
>
> > (*Many OO languages have the ability to "hide" certain of their
> > attributes from child objects. I haven't looked at PHP's spec in a
> > bit but I do not believe that it has the native ability to do so... I
> > could be very wrong.)
>
> Private (in this class only) vs protected (in this class and its
> descendants)? Yeah, it's got that.
Precisely so.
Good to know. I'll backpocket that bit o' info.
--
-Doug
Owen Winkler
>
> Hadn't tooled around the code enough to know whether such a beast as
> MediaBrowser exists yet.
You just haven't written it yet. ;)
Owen
Doug Stewart
Okay, so fleshing this out a bit before I do anything close to
committing "pen" to "paper":
The MediaBrowser class ought to handle streams of data (either the
native types it can handle or streams from plugins written to an API)
and output an XML stream of its own. The presentation layer ought to
be written in JS and be responsible for using AJAX-y freshness to do
all manner of coolness ala Michael's mockups. This keeps us in the
realm of MVC programming, although it is unclear to me whether we have
a defined scheme for making JS scripts part of the V. I will leave
that to someone far more skilled in JS coding and optimization.
I would almost advocate that the MB class know of NO data access
methods natively, allowing it to act as the C. Plugins could then act
as the M (I would suggest that a few default plugins be shipped and
enabled by default so that people don't have to go hunting for
something to display photos of their cats. *grin*).
What sort of metadata would the MB return to a JS presentation layer?
It obviously would need to vary by media type, but off the top of my
head, a few things to pursue:
-Local vs. remote files
-Iconography (be it thumbnails, YouTube default JPGs, or pretty little
MP3 icons)
-JPGs should have their EXIF data available
- MP3s/OGGs ought to have their ID3 info available
-tags associated with the media
-perhaps which plugin returned the data? (Flickr vs. Gallery vs.
Zooomr vs. an ftp dropbox, etc.)
Just spitballing here. Any additions to that list? (I'm sure there are many.)
-Doug