Draft block administration UI spec

[Chad Kieffer]

Hello,

I've posted a draft block administration UI spec on the codex and have  
added a link to this spec in the related Trac ticket. The UI takes  
queues from both Wordpress and Drupal block admin interfaces.

Feedback is welcome.

http://codex.gallery2.org/Gallery3:Block_Management_UX

thanks,
Chad

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chris F-2]

Hi,

Interesting document - just got a few questions, comments and points to think about regarding it, basically just thinking out loud.

The placement seems fine and logical - no issues i can see with that.

If you allow a block to be displayed in multiple areas, is there a way for a block to say "only display in sidebar if im not displayed in content"? Or another might be display in both. If you create a module where a theme blocks a certain location, you may want an alternate location to be displayed? Would this logic be better handled in the module through code or through the admin UI?

Are blocks always square shaped by nature? (as in a full sized div). If you would like to place icons directly above an image for example, would you use a block or not? Just thinking in addition to this - maybe the creation of an "icon" block that is displayed directly above an image that other modules/blocks can add their icon to the list?

In terms of zones/views (home, album, photo, etc). Are you able to define custom zones? If i created a page for example that is called exif which is a full screen representation of the exif details of an image - how would i define a block to show on this page?

In terms of writing a block module, will there be data passed easily to this? Eg album/photos, is there easy access to both of those bits of data?

I guess also in the calling of a block module, the location will be passed through to it so it can display differently depending on location - will this be the case?

Just thought i'd post a few of my ideas after reading the wiki about this part.

Hopefully it'll allow good customisation by modules with minimum effort.

Also i'm guessing that for this bit a lot of the internal functionality in g3 can be exposed as block modules to allow turning this on/off, changing location and easy customisation by authors if the block doesnt exactly suit their needs.

Cheers,

Chris

Chad Kieffer wrote:

Hello,

I've posted a draft block administration UI spec on the codex and have  
added a link to this spec in the related Trac ticket. The UI takes  
queues from both Wordpress and Drupal block admin interfaces.

Feedback is welcome.

http://codex.gallery2.org/Gallery3:Block_Management_UX

thanks,
Chad

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Kevin Nehls]

First let me say I think the layout looks great.  It's what people have been looking for, for a long time.

Just a comment about the same block being placed in multiple locations.  If we do allow the same block to be placed in multiple locations we need to make sure there is a way for the module developer to specify that a block can only be placed once on a page or something like that.

I've seen more than a few times where people placed more than one search block on a page in G2.  Since the search block uses javascript to clear the box when clicking into it, if you have multiple blocks on the page things don't work as expected and it confuses users.  I've also seen people put the Add Comments block on the page more than once and have confused themselves and their site visitors.  Visitors thinking they were putting a comment on an image, when it was just getting added to the album, etc.

Of course to make it more friendly we'd need to make it so if a module developer decided to limit how many blocks are placed on a page they would be able to define a user friendly message.  "You can only place one search block on a page."

Just some feedback from issues I've seen by users of G2.

Kevin (nivekiam)

On Sun, Jun 28, 2009 at 8:04 PM, Chris F-2 <lists@...> wrote:

Hi,

Interesting document - just got a few questions, comments and points to
think about regarding it, basically just thinking out loud.

The placement seems fine and logical - no issues i can see with that.

If you allow a block to be displayed in multiple areas, is there a way for a
block to say "only display in sidebar if im not displayed in content"? Or
another might be display in both. If you create a module where a theme
blocks a certain location, you may want an alternate location to be
displayed? Would this logic be better handled in the module through code or
through the admin UI?

------------------------------------------------------------------------------

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chad Kieffer]

Chris, Kevin, thanks for feedback.

On Jun 28, 2009, at 9:04 PM, Chris F-2 wrote:

> If you allow a block to be displayed in multiple areas, is there a  
> way for a
> block to say "only display in sidebar if im not displayed in  
> content"? Or
> another might be display in both. If you create a module where a theme
> blocks a certain location, you may want an alternate location to be
> displayed? Would this logic be better handled in the module through  
> code or
> through the admin UI?

Initially, at least, I doubt that we'll allow duplicate block  
placement. I can see, however, how this might be required at some  
point. Perhaps, at some point, block duplication through the admin UI  
would be allowed. I'll defer how this is handled to Bharat and Tim.

> Are blocks always square shaped by nature? (as in a full sized div).  
> If you
> would like to place icons directly above an image for example, would  
> you use
> a block or not? Just thinking in addition to this - maybe the  
> creation of an
> "icon" block that is displayed directly above an image that other
> modules/blocks can add their icon to the list?

Blocks are rectangular in shape. Blocks are not intended to be placed  
within the album or photo content region. I'm not sure what you intend  
to do here by placing icons.

> In terms of zones/views (home, album, photo, etc). Are you able to  
> define
> custom zones? If i created a page for example that is called exif  
> which is a
> full screen representation of the exif details of an image - how  
> would i
> define a block to show on this page?

I'm using the term region, rather than zone. If a module or G3 core  
provides a view then yes, it would have regions. Regions are defined  
across all views, you cannot assign a region to just one view.

> In terms of writing a block module, will there be data passed easily  
> to
> this? Eg album/photos, is there easy access to both of those bits of  
> data?

Not sure I understand what you mean here. Modules can provide blocks.  
What do you mean by a "block module"?

> I guess also in the calling of a block module, the location will be  
> passed
> through to it so it can display differently depending on location -  
> will
> this be the case?

No. My thinking is that blocks can be added to views, ordered within  
template regions, and that's it.

> Also i'm guessing that for this bit a lot of the internal  
> functionality in
> g3 can be exposed as block modules to allow turning this on/off,  
> changing
> location and easy customisation by authors if the block doesnt  
> exactly suit
> their needs.

The template system in G3 already allows theme developers to override  
a module's default block template within the theme (http://gallery.menalto.com/node/88326#comment-311328 
).

> Chad Kieffer wrote:
>>
>> Hello,
>>
>> I've posted a draft block administration UI spec on the codex and  
>> have
>> added a link to this spec in the related Trac ticket. The UI takes
>> queues from both Wordpress and Drupal block admin interfaces.
>>
>> Feedback is welcome.
>>
>> http://codex.gallery2.org/Gallery3:Block_Management_UX
>>
>> thanks,
>> Chad

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chris F-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

 

 

-----Original Message-----
From: Chad Kieffer [mailto:chad@...]
Sent: Monday, 29 June 2009 2:46 PM
To: Chris F-2
Cc: gallery-devel@...
Subject: Re: [Gallery-devel] Draft block administration UI spec

 

Chris, Kevin, thanks for feedback.

 

On Jun 28, 2009, at 9:04 PM, Chris F-2 wrote:

 

> If you allow a block to be displayed in multiple areas, is there a 

> way for a

> block to say "only display in sidebar if im not displayed in 

> content"? Or

> another might be display in both. If you create a module where a theme

> blocks a certain location, you may want an alternate location to be

> displayed? Would this logic be better handled in the module through 

> code or

> through the admin UI?

 

Initially, at least, I doubt that we'll allow duplicate block 

placement. I can see, however, how this might be required at some 

point. Perhaps, at some point, block duplication through the admin UI 

would be allowed. I'll defer how this is handled to Bharat and Tim.

 

======

 

So this will be handled on the admin side and not internally in the module? I guess that should be ok. I guess also if you place it twice in the admin (eg left and right side bar), then it should display as the admin has set it up that way, even if it is duplicated.

 

> Are blocks always square shaped by nature? (as in a full sized div). 

> If you

> would like to place icons directly above an image for example, would 

> you use

> a block or not? Just thinking in addition to this - maybe the 

> creation of an

> "icon" block that is displayed directly above an image that other

> modules/blocks can add their icon to the list?

 

Blocks are rectangular in shape. Blocks are not intended to be placed 

within the album or photo content region. I'm not sure what you intend 

to do here by placing icons.

 

======

 

What I was thinking here, was whether blocks are always square styled "widgets" or whether you can use them for other functionality?

 

Such as where you already have a set of icons being "view full size", "return to album", "view comments" and "view slideshow". Adding a block that contains another set of icons defined in a module that is placed in a different area.. for example 'content' just above the photo. That way I can add a block with the icons "view other sizes", 'view exif', etc.

 

Any reason why they can’t be included in the content region? I might decide to make an ‘exif’ block that will be displayed under the image. Or a ‘view comments’ block or a ‘forum url list’ block.

 

> In terms of zones/views (home, album, photo, etc). Are you able to 

> define

> custom zones? If i created a page for example that is called exif 

> which is a

> full screen representation of the exif details of an image - how 

> would i

> define a block to show on this page?

 

I'm using the term region, rather than zone. If a module or G3 core 

provides a view then yes, it would have regions. Regions are defined 

across all views, you cannot assign a region to just one view.

 

=====

 

How will these regions be defined? Will there be an admin for these if one wanted to add a new region (for example "footer2")? I assume there will be a bit of code that goes into views to define each region? What if I were to add a region that didn’t exist in one of my views?

 

> In terms of writing a block module, will there be data passed easily 

> to

> this? Eg album/photos, is there easy access to both of those bits of 

> data?

 

Not sure I understand what you mean here. Modules can provide blocks. 

What do you mean by a "block module"?

 

====

 

By this I mean simply a module that just provides a block with content in it and nothing else. Rather than a module that has a whole lot of other functionality other than blocks.

 

> I guess also in the calling of a block module, the location will be 

> passed

> through to it so it can display differently depending on location - 

> will

> this be the case?

 

No. My thinking is that blocks can be added to views, ordered within 

template regions, and that's it.

 

====

 

Reason I was thinking this, is my block might display differently in different regions. For example if it was in the right side bar I'd use a vertical list. If it was displayed in the footer I'd use a horizontal list.

 

Or would this be defined in the module itself.. that the block will only “fit” into certain size regions? (ie only side bars, or only header and footer)

 

> Also i'm guessing that for this bit a lot of the internal 

> functionality in

> g3 can be exposed as block modules to allow turning this on/off, 

> changing

> location and easy customisation by authors if the block doesnt 

> exactly suit

> their needs.

 

The template system in G3 already allows theme developers to override 

a module's default block template within the theme (http://gallery.menalto.com/node/88326#comment-311328

).

 

=====

 

For this I wasn't thinking display/html/css, more functionality and content.

 

Take for example the existing functionality on the right hand side of a photo called "photo info”. This currently displays “title”, “name” and “owner” of the active photo.

 

If this internal functionality was created as a block, I could easily take the code and modify it for my needs. I could for example create a module called “photo info 2” that displays “title”, “name”, “image size”, “image type”. I could then disable the g3 photo info block and display my own there instead.

 

Popular tags is a candidate for this, well as available rss feeds.

 

I’m thinking everything should be replaceable/movable in the side bars.

 

> Chad Kieffer wrote:

>> 

>> Hello,

>> 

>> I've posted a draft block administration UI spec on the codex and 

>> have

>> added a link to this spec in the related Trac ticket. The UI takes

>> queues from both Wordpress and Drupal block admin interfaces.

>> 

>> Feedback is welcome.

>> 

>> http://codex.gallery2.org/Gallery3:Block_Management_UX

>> 

>> thanks,

>> Chad

------------------------------------------------------------------------------

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Chad Kieffer]

Sorry forthe delayed reply.

On Jun 30, 2009, at 7:58 AM, "Chris F" <lists@...> wrote:

> ----Original Message-----
>
> Chris, Kevin, thanks for feedback.
>
>
>
>
> On Jun 28, 2009, at 9:04 PM, Chris F-2 wrote:
>
> > If you allow a block to be displayed in multiple areas, is there a
>
> > way for a
>
> > block to say "only display in sidebar if im not displayed in
>
> > content"? Or
>
> > another might be display in both. If you create a module where a  
> theme
>
> > blocks a certain location, you may want an alternate location to be
>
> > displayed? Would this logic be better handled in the module through
>
> > code or
>
> > through the admin UI?
>
>
>
> Initially, at least, I doubt that we'll allow duplicate block
>
> placement. I can see, however, how this might be required at some
>
> point. Perhaps, at some point, block duplication through the admin UI
>
> would be allowed. I'll defer how this is handled to Bharat and Tim.
>
> ======
>
> So this will be handled on the admin side and not internally in the  
> module? I guess that should be ok. I guess also if you place it  
> twice in the admin (eg left and right side bar), then it should  
> display as the admin has set it up that way, even if it is duplicated.
>

It makes sense that a module would define whether or not a block it  
provides may duplicated. I suppose your right, Gallery's core and  
theme system wouldn't be responsible for this aspect, just the storage  
and retrieval of block placement settings.

> > Are blocks always square shaped by nature? (as in a full sized div).
>
>
> > If you
>
> > would like to place icons directly above an image for example, would
>
> > you use
>
> > a block or not? Just thinking in addition to this - maybe the
>
> > creation of an
>
> > "icon" block that is displayed directly above an image that other
>
> > modules/blocks can add their icon to the list?
>
>
>
> Blocks are rectangular in shape. Blocks are not intended to be placed
>
> within the album or photo content region. I'm not sure what you intend
>
> to do here by placing icons.
>
> ======
>
> What I was thinking here, was whether blocks are always square  
> styled "widgets" or whether you can use them for other functionality?
>
> Such as where you already have a set of icons being "view full  
> size", "return to album", "view comments" and "view slideshow".  
> Adding a block that contains another set of icons defined in a  
> module that is placed in a different area.. for example 'content'  
> just above the photo. That way I can add a block with the icons  
> "view other sizes", 'view exif', etc.
>
> Any reason why they can’t be included in the content region? I might
>  decide to make an ‘exif’ block that will be displayed under the  
> image. Or a ‘view comments’ block or a ‘forum url list’ block.
>

This seems to be beyond the scope of block management. Sure, modules  
can provide links and buttons, but these should be assigned to menus,  
not blocks. The menus themselves are blocks, I suppose.

Anything beyond this seems out of scope for most.

> > In terms of zones/views (home, album, photo, etc). Are you able to
>
>
> > define
>
> > custom zones? If i created a page for example that is called exif
>
> > which is a
>
> > full screen representation of the exif details of an image - how
>
> > would i
>
> > define a block to show on this page?
>
>
>
> I'm using the term region, rather than zone. If a module or G3 core
>
> provides a view then yes, it would have regions. Regions are defined
>
> across all views, you cannot assign a region to just one view.
>
> =====
>
> How will these regions be defined? Will there be an admin for these  
> if one wanted to add a new region (for example "footer2")? I assume  
> there will be a bit of code that goes into views to define each  
> region? What if I were to add a region that didn’t exist in one of m
> y views?
>

They'll be defined in the theme.info file in each theme. The view  
templates will need to have a corresponding variable in them to mark  
the location of each.

> > In terms of writing a block module, will there be data passed easily
>
>
> > to
>
> > this? Eg album/photos, is there easy access to both of those bits of
>
> > data?
>
>
>
> Not sure I understand what you mean here. Modules can provide blocks.
>
> What do you mean by a "block module"?
>
> ====
>
> By this I mean simply a module that just provides a block with  
> content in it and nothing else. Rather than a module that has a  
> whole lot of other functionality other than blocks.
>

Sounds like you might want to override a module template. You can do  
this already and I would expect that block template for modules would  
be no different.

> > I guess also in the calling of a block module, the location will be
>
>
> > passed
>
> > through to it so it can display differently depending on location -
>
> > will
>
> > this be the case?
>
>
>
> No. My thinking is that blocks can be added to views, ordered within
>
> template regions, and that's it.
>
> ====
>
> Reason I was thinking this, is my block might display differently in  
> different regions. For example if it was in the right side bar I'd  
> use a vertical list. If it was displayed in the footer I'd use a  
> horizontal list.
>
> Or would this be defined in the module itself.. that the block will  
> only “fit” into certain size regions? (ie only side bars, or only  
> header and footer)
>

I would control this with CSS descenent selectors, like this:

#gAlbumGrid .moduleBlock {...}

#gSidebar .moduleBlock {...}

This method is currently used in the default theme to do just this.

> > Also i'm guessing that for this bit a lot of the internal
>
>
> > functionality in
>
> > g3 can be exposed as block modules to allow turning this on/off,
>
> > changing
>
> > location and easy customisation by authors if the block doesnt
>
> > exactly suit
>
> > their needs.
>
> The template system in G3 already allows theme developers to override
>
> a module's default block template within the theme (http://gallery.menalto.com/node/88326#comment-311328 
> ).
>
> =====
>
> For this I wasn't thinking display/html/css, more functionality and  
> content.
>
> Take for example the existing functionality on the right hand side  
> of a photo called "photo info”. This currently displays  
> “title”, “name” and “owner” of the active photo.
>
> If this internal functionality was created as a block, I could  
> easily take the code and modify it for my needs. I could for example  
> create a module called “photo info 2” that displays “title”,  
> “name”, “image size”, “image type”. I could then disable  
> the g3 photo info block and display my own there instead.
>
> Popular tags is a candidate for this, well as available rss feeds.
>
> I’m thinking everything should be replaceable/movable in the side ba
> rs.
>

Sure.

>  Chad Kieffer wrote:
>
> Hello,
>
> I've posted a draft block administration UI spec on the codex and  
> have added a link to this spec in the related Trac ticket. The UI  
> takes queues from both Wordpress and Drupal block admin interfaces.
>
>
> Feedback is welcome. http://codex.gallery2.org/Gallery3:Block_Management_UX
>
>  thanks,
>
> Chad
>

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

I did a quick once-over on your design.

The separation of placement and visibility seems a little heavy to me.
Seems to me that most people want to show blocks on most pages, with a
few small tweaks.  Perhaps checkboxes (or some more efficient widget)
inside the block itself would allow us to do it all on one page.

The sidebar config UI can look at the theme to find out which regions
are available and create a series of boxes for them.  It can look at all
the modules to find out which blocks are available, and we can drag and
drop them together.

For simplicity I suggest:
1) The UI assumes that blocks are not configurable.  Adding
configuration support is non-trivial and needs some thought.

2) We have a limited number of regions and display them all at all
times, and gray out the regions which the current theme doesn't support.
 This will greatly simplify the UI rendering problem and avoid a
combinatorics problem in supporting the code.

3) We work really hard to get it onto one page so that we can get rid of
the visibility tab and the extra page.

4) We get rid of [+ Create a block].  That can be done in a custom module.

5) We come up with an "Available blocks" widget that can handle at least
20+ different blocks.  If we're not doing editability, it means that
modules are going to export more block alternatives (eg: "Latest images:
few", "Latest images: many", etc).

Chad Kieffer wrote:

> Sorry forthe delayed reply.
>
> On Jun 30, 2009, at 7:58 AM, "Chris F" <lists@...> wrote:
>> ----Original Message-----
>>
>> Chris, Kevin, thanks for feedback.
>>
>>
>>
>>
>> On Jun 28, 2009, at 9:04 PM, Chris F-2 wrote:
>>
>>> If you allow a block to be displayed in multiple areas, is there a
>>> way for a
>>> block to say "only display in sidebar if im not displayed in
>>> content"? Or
>>> another might be display in both. If you create a module where a  
>> theme
>>
>>> blocks a certain location, you may want an alternate location to be
>>> displayed? Would this logic be better handled in the module through
>>> code or
>>> through the admin UI?
>>
>>
>> Initially, at least, I doubt that we'll allow duplicate block
>>
>> placement. I can see, however, how this might be required at some
>>
>> point. Perhaps, at some point, block duplication through the admin UI
>>
>> would be allowed. I'll defer how this is handled to Bharat and Tim.
>>
>> ======
>>
>> So this will be handled on the admin side and not internally in the  
>> module? I guess that should be ok. I guess also if you place it  
>> twice in the admin (eg left and right side bar), then it should  
>> display as the admin has set it up that way, even if it is duplicated.
>>
> It makes sense that a module would define whether or not a block it  
> provides may duplicated. I suppose your right, Gallery's core and  
> theme system wouldn't be responsible for this aspect, just the storage  
> and retrieval of block placement settings.
>
>
>>> Are blocks always square shaped by nature? (as in a full sized div).
>>
>>> If you
>>> would like to place icons directly above an image for example, would
>>> you use
>>> a block or not? Just thinking in addition to this - maybe the
>>> creation of an
>>> "icon" block that is displayed directly above an image that other
>>> modules/blocks can add their icon to the list?
>>
>>
>> Blocks are rectangular in shape. Blocks are not intended to be placed
>>
>> within the album or photo content region. I'm not sure what you intend
>>
>> to do here by placing icons.
>>
>> ======
>>
>> What I was thinking here, was whether blocks are always square  
>> styled "widgets" or whether you can use them for other functionality?
>>
>> Such as where you already have a set of icons being "view full  
>> size", "return to album", "view comments" and "view slideshow".  
>> Adding a block that contains another set of icons defined in a  
>> module that is placed in a different area.. for example 'content'  
>> just above the photo. That way I can add a block with the icons  
>> "view other sizes", 'view exif', etc.
>>
>> Any reason why they can’t be included in the content region? I might
>>  decide to make an ‘exif’ block that will be displayed under the  
>> image. Or a ‘view comments’ block or a ‘forum url list’ block.
>>
> This seems to be beyond the scope of block management. Sure, modules  
> can provide links and buttons, but these should be assigned to menus,  
> not blocks. The menus themselves are blocks, I suppose.
>
> Anything beyond this seems out of scope for most.
>
>>> In terms of zones/views (home, album, photo, etc). Are you able to
>>
>>> define
>>> custom zones? If i created a page for example that is called exif
>>> which is a
>>> full screen representation of the exif details of an image - how
>>> would i
>>> define a block to show on this page?
>>
>>
>> I'm using the term region, rather than zone. If a module or G3 core
>>
>> provides a view then yes, it would have regions. Regions are defined
>>
>> across all views, you cannot assign a region to just one view.
>>
>> =====
>>
>> How will these regions be defined? Will there be an admin for these  
>> if one wanted to add a new region (for example "footer2")? I assume  
>> there will be a bit of code that goes into views to define each  
>> region? What if I were to add a region that didn’t exist in one of m
>> y views?
>>
> They'll be defined in the theme.info file in each theme. The view  
> templates will need to have a corresponding variable in them to mark  
> the location of each.
>
>>> In terms of writing a block module, will there be data passed easily
>>
>>> to
>>> this? Eg album/photos, is there easy access to both of those bits of
>>> data?
>>
>>
>> Not sure I understand what you mean here. Modules can provide blocks.
>>
>> What do you mean by a "block module"?
>>
>> ====
>>
>> By this I mean simply a module that just provides a block with  
>> content in it and nothing else. Rather than a module that has a  
>> whole lot of other functionality other than blocks.
>>
> Sounds like you might want to override a module template. You can do  
> this already and I would expect that block template for modules would  
> be no different.
>
>>> I guess also in the calling of a block module, the location will be
>>
>>> passed
>>> through to it so it can display differently depending on location -
>>> will
>>> this be the case?
>>
>>
>> No. My thinking is that blocks can be added to views, ordered within
>>
>> template regions, and that's it.
>>
>> ====
>>
>> Reason I was thinking this, is my block might display differently in  
>> different regions. For example if it was in the right side bar I'd  
>> use a vertical list. If it was displayed in the footer I'd use a  
>> horizontal list.
>>
>> Or would this be defined in the module itself.. that the block will  
>> only “fit” into certain size regions? (ie only side bars, or only  
>> header and footer)
>>
> I would control this with CSS descenent selectors, like this:
>
> #gAlbumGrid .moduleBlock {...}
>
> #gSidebar .moduleBlock {...}
>
> This method is currently used in the default theme to do just this.
>
>>> Also i'm guessing that for this bit a lot of the internal
>>
>>> functionality in
>>> g3 can be exposed as block modules to allow turning this on/off,
>>> changing
>>> location and easy customisation by authors if the block doesnt
>>> exactly suit
>>> their needs.
>> The template system in G3 already allows theme developers to override
>>
>> a module's default block template within the theme (http://gallery.menalto.com/node/88326#comment-311328 
>> ).
>>
>> =====
>>
>> For this I wasn't thinking display/html/css, more functionality and  
>> content.
>>
>> Take for example the existing functionality on the right hand side  
>> of a photo called "photo info”. This currently displays  
>> “title”, “name” and “owner” of the active photo.
>>
>> If this internal functionality was created as a block, I could  
>> easily take the code and modify it for my needs. I could for example  
>> create a module called “photo info 2” that displays “title”,  
>> “name”, “image size”, “image type”. I could then disable  
>> the g3 photo info block and display my own there instead.
>>
>> Popular tags is a candidate for this, well as available rss feeds.
>>
>> I’m thinking everything should be replaceable/movable in the side ba
>> rs.
>>
> Sure.
>
>>  Chad Kieffer wrote:
>>
>> Hello,
>>
>> I've posted a draft block administration UI spec on the codex and  
>> have added a link to this spec in the related Trac ticket. The UI  
>> takes queues from both Wordpress and Drupal block admin interfaces.
>>
>>
>> Feedback is welcome. http://codex.gallery2.org/Gallery3:Block_Management_UX
>>
>>  thanks,
>>
>> Chad
>>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]