Mailing List Archive

Hi Aaron,

let me stop you here a bit. :)
Do follow the order of the elements. Please! Element ordering is
essential to Bricolage subelement model so do keep things as they are.
Related story/media are just as elements as any other.

Regards, Zdravko

Aaron Fuleki wrote:
> ------------------------------------------------------------------------
> Simplify the related media/story section of container elements.
> ------------------------------------------------------------------------
>
> Suggested Changes:
> * Only show the full table of related object info once expanded.
> * UUID could probably move down, be removed, become a tooltip, etc.
> * Edit icon pops up relation dialog (maintain right corner convention).
> * Child elements would work the same as they do now (but icons inside),
> appearing in order above any related story/media blocks.
> * Related story/media blocks probably shouldn't be draggable.
>
>
> -Aaron
>
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>

Zdravko,

I'm a bit confused. From a user's standpoint, how is the related object's order amongst elements important? Is it even preserved? As far as I know, they're just object IDs related to the element records, but I'm not intimately familiar with the database schema.

All the user should care about is establishing a relationship between two content objects, preferably in a consistent, easy-to-inderstand way. Allowing the structure of a database schema or API to influence the functional design of the user interface is rarely a good idea, unless it reinforces a pervasive data model that's integral to the user's understanding of an application. Even then, it's probably not a good idea.

This would probably make a lot more sense if the mailing list engine hadn't stripped my images from the original post. I wasn't suggesting that we mess with where relations appear with respect to the overall story profile, just with respect their parent elements. When images fail, ASCII art prevails; set your readers to fixed-width, please ;-)

-----------------------------------------
| My Awesome Story
| * Title
| * Cover Date
| * etc.
|----------------------------------------
| Container Element 1
| * Child Field 1 \
| * Child Field 2 > can be dragged
| * Child Field 3 /
| * Related Story \ can't be dragged
| * Related Media /
|----------------------------------------
| Field 4
|----------------------------------------
| Container Element 2
| * Child Field 1
| * Child Field 2
| * Related Story
|----------------------------------------
| Container Element 3
| * Child Element 1
| * Child Element 2
|----------------------------------------
| Related Story (can't be dragged)
|----------------------------------------
| Related Media (can't be dragged)
-----------------------------------------

To explain the above:
If a story element can have related stories or media, they would float to the bottom, and not be reorder-able. If their order makes no difference, then consistency wins. Likewise, if container elements have related stories or media, they float to the bottom of said container, and are also immobile.

Anything that makes the UI more consistent reduces learning curve and confusion. Reliable placement of like elements leverages a user's spatial memory, further increasing their chances of successful use.

Does that make more sense, or did I just over-explain it? :-)

-Aaron

---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------



On Apr 5, 2011, at 1:13 AM, Zdravko Balorda wrote:

>
> Hi Aaron,
>
> let me stop you here a bit. :)
> Do follow the order of the elements. Please! Element ordering is
> essential to Bricolage subelement model so do keep things as they are.
> Related story/media are just as elements as any other.
>
> Regards, Zdravko
>
> Aaron Fuleki wrote:
>> ------------------------------------------------------------------------
>> Simplify the related media/story section of container elements.
>> ------------------------------------------------------------------------
>> Suggested Changes:
>> * Only show the full table of related object info once expanded.
>> * UUID could probably move down, be removed, become a tooltip, etc.
>> * Edit icon pops up relation dialog (maintain right corner convention).
>> * Child elements would work the same as they do now (but icons inside),
>> appearing in order above any related story/media blocks.
>> * Related story/media blocks probably shouldn't be draggable.
>> -Aaron
>> ---------------------------------
>> Aaron Fuleki
>> Senior Web Architect
>> Denison University
>> 740.587.5752
>> ---------------------------------
>

Aaron, hi!

Well, I think I could go with less specifications. :)

I see your point. However templating is not that smart. Users are sometimes required to
care about positioning elements too, not just about relationships. So related media/story
should be dragable, because order matters. Or may matter. More specifically, you have
a whole interface in Story object: $element->get_elements; where one can manipulate things
based on order number. It's not just IDs. Or else you could make everything not to be
draged. Why bother.

I don't see that you can just blow it away, not even for the expence of UI consistency,
or learning curve, or confusion. I must disagree with you here.

It's still just a computer program even though it's Bricolage.

Regards, Zdravko

Zdravko,

That's where I think our understanding differs. The only connection between related items and their elements that I'm aware of are the story_element.related_story__id and story_element.related_media__id fields. There is no notion of ordering related objects that I can find, other than an order they might inherit from a parent object.

I wasn't suggesting that any element or field not be order-able, just that we put related media and objects in a consistent place, and not let you move them if moving them is pointless.

Sometimes a simple constraint can make an interface that much easier to use.

Now, am I bonkers? Do relations actually have an order exposed in the template API, other than what might be inherited from a container?

-Aaron

---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------



On Apr 5, 2011, at 9:35 AM, Zdravko Balorda wrote:

>
> Aaron, hi!
>
> Well, I think I could go with less specifications. :)
>
> I see your point. However templating is not that smart. Users are sometimes required to
> care about positioning elements too, not just about relationships. So related media/story
> should be dragable, because order matters. Or may matter. More specifically, you have
> a whole interface in Story object: $element->get_elements; where one can manipulate things
> based on order number. It's not just IDs. Or else you could make everything not to be
> draged. Why bother.
>
> I don't see that you can just blow it away, not even for the expence of UI consistency,
> or learning curve, or confusion. I must disagree with you here.
>
> It's still just a computer program even though it's Bricolage.
>
> Regards, Zdravko

Hi everybody,

I'm sure Aaron's right. An element can contain the following:

1. An arbitrary number of fields.
2. An arbitrary number of subelements.
3. At most one related story
4. At most one related media document.

Calling $element->get_elements returns a list of fields and subelements.
If there is a related story or a related media document, it is not in
that list. Instead, those assets can be accessed using
$element->get_related_story and $element->get_related_media.

So it makes sense that the related-story and related-media assets stay
out of the element flow. But isn't that already true?

Maybe this is where screenshots would be a good idea...


Cheers,

Bret


On Tue, 2011-04-05 at 10:19 -0400, Aaron Fuleki wrote:
> Zdravko,
>
> That's where I think our understanding differs. The only connection between related items and their elements that I'm aware of are the story_element.related_story__id and story_element.related_media__id fields. There is no notion of ordering related objects that I can find, other than an order they might inherit from a parent object.
>
> I wasn't suggesting that any element or field not be order-able, just that we put related media and objects in a consistent place, and not let you move them if moving them is pointless.
>
> Sometimes a simple constraint can make an interface that much easier to use.
>
> Now, am I bonkers? Do relations actually have an order exposed in the template API, other than what might be inherited from a container?
>
> -Aaron
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>
>
>
> On Apr 5, 2011, at 9:35 AM, Zdravko Balorda wrote:
>
> >
> > Aaron, hi!
> >
> > Well, I think I could go with less specifications. :)
> >
> > I see your point. However templating is not that smart. Users are sometimes required to
> > care about positioning elements too, not just about relationships. So related media/story
> > should be dragable, because order matters. Or may matter. More specifically, you have
> > a whole interface in Story object: $element->get_elements; where one can manipulate things
> > based on order number. It's not just IDs. Or else you could make everything not to be
> > draged. Why bother.
> >
> > I don't see that you can just blow it away, not even for the expence of UI consistency,
> > or learning curve, or confusion. I must disagree with you here.
> >
> > It's still just a computer program even though it's Bricolage.
> >
> > Regards, Zdravko
>
>

--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

On Apr 5, 2011, at 7:58 AM, Bret Dawson wrote:

> So it makes sense that the related-story and related-media assets stay
> out of the element flow. But isn't that already true?

If not, it's a bug.

Best,

David

On Apr 4, 2011, at 8:25 AM, Aaron Fuleki wrote:

> * Only show the full table of related object info once expanded.
> * UUID could probably move down, be removed, become a tooltip, etc.
> * Edit icon pops up relation dialog (maintain right corner convention).
> * Child elements would work the same as they do now (but icons inside),
> appearing in order above any related story/media blocks.
> * Related story/media blocks probably shouldn't be draggable.

+1

David

David E. Wheeler wrote:
> On Apr 5, 2011, at 7:58 AM, Bret Dawson wrote:
>
>> So it makes sense that the related-story and related-media assets stay
>> out of the element flow. But isn't that already true?
>
> If not, it's a bug.
>

Why?
If you want to place two images in a row, how will you decide which
one is first? And why shouldn't they appear in between other elements?

Zdravko

Bret Dawson wrote:
> Hi everybody,
>
> I'm sure Aaron's right. An element can contain the following:
>
> 1. An arbitrary number of fields.
> 2. An arbitrary number of subelements.
> 3. At most one related story
> 4. At most one related media document.

why can't an element contain arbitrary number of related media?


> Calling $element->get_elements returns a list of fields and subelements.
> If there is a related story or a related media document, it is not in
> that list. Instead, those assets can be accessed using
> $element->get_related_story and $element->get_related_media.

It's not? Am I missing something here?

Regards, Zdravko

On Apr 6, 2011, at 1:27 AM, Zdravko Balorda wrote:
> why can't an element contain arbitrary number of related media?

Based on what I assumed, and others have confirmed, the relationship between related stories/media and their parent element is strictly 1-to-1. They're just columns in the story_element table, nothing more. There is no way in the database or API to give them order; they are not true elements, and they are not given an entry in any of the element tables.

That said, there's nothing stopping you from creating a container element whose express purpose is holding a related media or story. We have an element called "Photo Section", which can hold any number of "Photo" elements. All those elements have is a caption field and a related media. You can add as many as you want, and order them however you want.

-Aaron

---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------

Aaron, hi!
Isn't "Photo Section" a parent for "Photo" elements in your case?

Well, I may be just too tired, and you use different words for the same
thing. If you want to say that related media element can contain only one
media, you are right.
But generally, AN element can contain any number of related-media (sub)elements.
Containers are elements, too.

Now, let me get back to your scheme:
| Container Element 1
| * Child Field 1 \
| * Child Field 2 > can be dragged
| * Child Field 3 /
| * Related Story \ can't be dragged
| * Related Media /

One should be able to do this for instance:

| Container Element 1
| * Child Field 1 \
| * Child Field 2 > can be dragged
| * Related Media 3 /
| * Child Field 4 /
| * Related Media 5 /
| * Related Story 6 can be dragged, too.
| * Child Container Element x.... and so on.

This is fundamental. You see, there can be more than one related media in a container.

Only if you speak about related media element itself, then what you are saying is true.
Related media element can have only one media document related to. But general container
(element) can have as many related media element as one needs.

Hopefully we will get our wording right, to discuss the same thing. :)

Regards, Zdravko




Aaron Fuleki wrote:
> On Apr 6, 2011, at 1:27 AM, Zdravko Balorda wrote:
>> why can't an element contain arbitrary number of related media?
>
> Based on what I assumed, and others have confirmed, the relationship between related stories/media and their parent element is strictly 1-to-1. They're just columns in the story_element table, nothing more. There is no way in the database or API to give them order; they are not true elements, and they are not given an entry in any of the element tables.
>
> That said, there's nothing stopping you from creating a container element whose express purpose is holding a related media or story. We have an element called "Photo Section", which can hold any number of "Photo" elements. All those elements have is a caption field and a related media. You can add as many as you want, and order them however you want.
>
> -Aaron
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>
>

On 2011-04-05, at 9:07 AM, Aaron Fuleki wrote:

> If a story element can have related stories or media, they would float to the bottom, and not be reorder-able. If their order makes no difference, then consistency wins. Likewise, if container elements have related stories or media, they float to the bottom of said container, and are also immobile.


+1

--
Phillip Smith
http://phillipadsmith.com
http://twitter.com/phillipadsmith
http://linkedin.com/in/phillipadsmith

On 06/04/2011 14:19, Zdravko Balorda wrote:
>
> Only if you speak about related media element itself, then what you
> are saying is true.
> Related media element can have only one media document related to. But
> general container
> (element) can have as many related media element as one needs.

(Please excuse the clumsy highlighting)

This is an issue with understanding how the element model works. I
suspect that allowing an ELEMENT to have a related media ITEM and
creating a default container element also called related media is the
basis of the confusion.

Any element can only have one related media ITEM. It's hard coded into
the table.

If your element requires more than one related media item you need to
create a (sub-)element to represent a related media item and include
that multiple times. Each of those sub-elements can have only one
related media item DIRECTLY associated with it.

A general container element cannot have as many related media items as
it wants, it can only have one. To have more you need to include
multiple sub-elements.

Confusing, isn't it :-/

Simon.

--
Digital Craftsmen Ltd
New Broad Street House, 35 New Broad Street, London. EC2M 1NH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcraftsmen.net/

On Apr 6, 2011, at 6:48 AM, Simon Wilcox wrote:

> Any element can only have one related media ITEM. It's hard coded into the table.
>
> If your element requires more than one related media item you need to create a (sub-)element to represent a related media item and include that multiple times. Each of those sub-elements can have only one related media item DIRECTLY associated with it.
>
> A general container element cannot have as many related media items as it wants, it can only have one. To have more you need to include multiple sub-elements.
>
> Confusing, isn't it :-/

Thanks for this, Simon, well stated and exactly right.

Best,

David