Art packs - How I envision them
Thursday, August 13, 2009 - 17:18
EDIT: see "sanity check" below. While this list might work as a feature list for a ground-up application, the sanity check takes a much more pragmatic approach.
An artpack is one of (but not both at the same time):
- a set of "links" (references) to other artpacks
- references works as "directories", ie. they are not flattened (avoids recursion problems)
- conceptually an image is simply an artpack with a single element; more on this later
- can not include references to the type below
- a "list" of set operations that can be performed on other artpacks (sets) and metadata (see below) to determine the contents
- can freely flatten the toplevel of the first variant of artpacks
-
can copy, but not include (flattened), other artpacks of this type; more on this below
- can include unflattened artpacks of this type
that
- can have associated "metadata" - creation time, description, contributors, number of pieces - whatever (depends on what we end up using them for)
- (wishlist) can be sorted
- by metadata in the contained artpacks
- by "sort-order" info in the artpacks, allowing eg. manual ordering
- (whishlist and libraries / performance allow) are partially ordered (ie. partially ordered sets)
- (wishlist) can be cooperative, with per-user / per-usergroup permission (user groups could theoretically be implemented as "art
packs" ;))
- (whishlist) can be published / private to a user
which would allow us to use them for
- user art packs (obviously)
- user art collections (same as above?)
- "official" art packs (restricted, pushed to page)
- automatically generated art packs - anything goes here, really - by users/projects, most favourites/most views, by licenses etc.
- "Archives" (entries containing multiple images/files)
- Project pages
- "tagging"
- ...medal handling? Ok, ok, I know :p.
- More? I'd say as much as we want to, but we need to find a balance.
I might have pushed it a little, but this is the general idea anyway. Art packs are sets of (art-pack) references. "Submission/Entries" are ideally also "just an artpack". Scary huh? Anyway, this needs some clarification, but it will have to wait until I know what needs clarification, so ask away ^^. Keep in mind that this doesn't really take the Drupal/Database reality into account - it will need some sanity-checks.
Here's the sane version:
This implements a substantial part of the feature set above - the rest can probably be implemented "on top" if the need arises.
UI idea:
This is a decent interface IMO - faster if not simpler than deviantArt style drag and drop in many cases.