Mailing List Archive: [Bricolage-General] Element Redesign Feedback Requested

[Bricolage-General] Element Redesign Feedback Requested

Dec 6, 2002, 10:22 AM

Post #1 of 4 (1456 views)

Hi All,

There has been a lot of text going back and forth between Mark and me
on the development list with regard to the proposed element redesign,
and I'm working on a new version of the RFC. But before I release it, I
wanted to send this briefer message with some specific ideas that I
want to get feedback on. Please read each of these points and respond
with your opinions; I expect it will take you about 10 minutes, and it
may well affect the design of the next major release of Bricolage.
Thanks!

Merge Story and Media
=====================
I propose to dump the distinction between stories and media and create
a new, unified concept, "Document". A new field type will be an upload
field, and that's how media will be associated with a document. To
manage media assets through workflow, you'll be able to create document
types with a single upload field. Auto-populated fields will be handled
as media object attributes, instead of as field elements.

Upshot
------
How do you feel about having "Story" and "Media" merged into the single
concept of a "Document" in Bricolage? How will this hurt/help how you
work with Bricolage in the future?

Dump Element Types
==================
Many of the properties of what we now call "Element Types" will be
removed by the element redesign, leaving very little use for this
higher-level grouping of elements. I propose to dump this level of
indirection.

Upshot
------
How do you feel about managing Elements only, with no more Element
Types to group them?

Separate Document Definition from Element Definition
====================================================
I propose to have separate administrative interfaces for document
definitions (or story types and media types, if we don't merge them
[see idea 1]) and for subelements. This is just because they're
conceptually different to end-users. You define elements via the
Element manager, and documents via the Document manager. They would
likely be built from the same code, but would maintain the distinction
of the concepts of top-level element vs. subelements.

Upshot
------
What do you think of the idea of separate Document Manager and Element
Manager interfaces?

Spelling
========
Upshot
------
Shall we spell it "Subelement" or "Sub-element" or "Sub-Element"?

Thank you for your feedback!

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Re: [Bricolage-General] Element Redesign Feedback Requested [ In reply to ]

david at wheeler

Dec 6, 2002, 11:20 AM

Post #2 of 4 (1406 views)

Permalink

On Friday, December 6, 2002, at 11:18 AM, Sérgio Nunes wrote:

> Hi,
>
> I'm still *fighting* :) with the installation of bricolage so I'm only
> able to comment the last question.

Fight on, brave warrior! You shall prevail! :-)

> David Wheeler wrote:
> > Spelling
> > ========
> > Upshot
> > ------
> > Shall we spell it "Subelement" or "Sub-element" or "Sub-Element"?
>
> My vote: Sub-element
> Because subelement as a word does not exists, so I think it's better
> to present it separated.

Thanks! I'll have to add up the votes and see where they fall.

Regards,

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Re: [Bricolage-General] Element Redesign Feedback Requested [ In reply to ]

drowsy at mac

Dec 6, 2002, 1:51 PM

Post #3 of 4 (1402 views)

Permalink

David,

> Merge Story and Media
> =====================

I think it sounds good, especially if the concept of document typing is
flexible.

1. How will the searching for related documents/stories/media be
affected? Will this allow us to zero in on the doc types as part of
the search?
2. By auto-populated fields, you mean all input types that have
defaults? Is this to facilitate later editing of a select list, for
example? Are fields that do not have defaults different animals, or
are all fields media object attributes, or will some field elements
have media object attributes belonging to them?

> Dump Element Types
> ==================

I'd be happy to see things get less regimented, leaving it up to the
admins which subelements are available to a given element.

>
> Separate Document Definition from Element Definition
> ====================================================

Hmmm...
That might make it a lot easier to work out basic permissions. This
might be good for admins who wish to allow folks to assemble new doc
types from a stable of elements, without giving folks access to the
element screens.

I guess this would make the interface cleaner in another way too: If
you need to define metadata fields as part of the doc element, you can
create otherwise identical types that have different metadata sets for
different doc types (Dublin Core for internal use, NTIF for syndication
etc).

Of course TMTOWTDI, these metadata sets could be subelements that could
be selected for one doc type, but then it relies on active inclusion on
the part of the user.

Thanks for bricolage,
Mike

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Re: [Bricolage-Devel] Re: [Bricolage-General] Element Redesign Feedback Requested [ In reply to ]

david at wheeler

Dec 6, 2002, 2:53 PM

Post #4 of 4 (1403 views)

Permalink

On Friday, December 6, 2002, at 01:51 PM, drowsy@mac.com wrote:

>> Merge Story and Media
>> =====================
>
> I think it sounds good, especially if the concept of document typing
> is flexible.

Yes, that's the idea.

> 1. How will the searching for related documents/stories/media be
> affected? Will this allow us to zero in on the doc types as part of
> the search?

Yes. We can add that to Bricolage now without too much trouble. It will
be even better integrated in the Element revision, though.

> 2. By auto-populated fields, you mean all input types that have
> defaults? Is this to facilitate later editing of a select list, for
> example? Are fields that do not have defaults different animals, or
> are all fields media object attributes, or will some field elements
> have media object attributes belonging to them?

No, I'm sorry, I haven't been clear. Auto-populated fields are those
fields in media asset profiles that are populated by Bricolage when you
upload a media file. For example, if you create a new Media Element and
make it's type "Image", and then create a new media asset of that type,
you'll notice a number of default fields will appear (height, width,
resolution etc.). When you upload a media file to the new media asset
you've created, Bricolage will fill in the values for these
auto-populated fields.

This doesn't work with the default Image media types that come with
Bricolage because I never got 'round to fixing them. But you can do it
now with new Media Element definitions.

So what I propose is to not make these field elements at all, but
properties of the media element subclasses, much as file size is, now.

As to your other questions, fields without defaults are the same as
those with defaults, except that they don't have defaults. Fields are
not media object attributes (or won't be in the redesign), and field
elements won't have media object attributes. Fields are just fields
that can be filled in by users.

>> Dump Element Types
>> ==================
>
> I'd be happy to see things get less regimented, leaving it up to the
> admins which subelements are available to a given element.

Well, that's up to them now, isn't it? I'm just talking about
eliminating a largely unnecessary level of complexity.

>> Separate Document Definition from Element Definition
>> ====================================================
>
> Hmmm...
> That might make it a lot easier to work out basic permissions. This
> might be good for admins who wish to allow folks to assemble new doc
> types from a stable of elements, without giving folks access to the
> element screens.

Ah, yes, good point.

> I guess this would make the interface cleaner in another way too: If
> you need to define metadata fields as part of the doc element, you can
> create otherwise identical types that have different metadata sets for
> different doc types (Dublin Core for internal use, NTIF for
> syndication etc).
>
> Of course TMTOWTDI, these metadata sets could be subelements that
> could be selected for one doc type, but then it relies on active
> inclusion on the part of the user.

Right.

Thanks for the feedback!

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general