Mailing List Archive: Bricolage: devel

bricolage enhancements

Index | Next | Previous | View Threaded

alex at gossamer-threads

Jan 28, 2009, 10:13 PM

Post #1 of 12 (3381 views)
Permalink

bricolage enhancements

Hi,

We've been tasked to do a series of enhancements to Bricolage for the World
Health Organization and I'm happy to say that one of the goals of this
project is to make sure that we can get as much committed back into the
project as possible.

I just wanted to outline briefly what we will be undertaking and then
we'll be following up with some implementation and design questions to
make sure what we do makes sense with Bricolage as a whole and we're
able to get it put back into svn.

We're looking at the following enhancements:

* Editable Preview - when you have a story checked out and then preview
it, we want to add the ability to be able to click in any paragraph
block and have the text editable. This allows for quick typo fixes and
other minor text changes to be made while previewing a document.

* Copy and Paste - beside each element, we want to add a copy feature
that will copy the element into a copy buffer. Then on the existing
story or on a new story, we will adjust the insert element menu to also
include a Paste option (assuming the element currently in the copy
buffer is allowed).

* Word Import - this may end up in contrib as we aren't sure how generic
it can be made. The goal is that on the new story page, you will be able
to upload a word file created with a predefined style sheet. The word
file will be parsed and the meta info pulled from the document
properties and the elements created from the document itself giving you
a pre-populated story that you can then tweak and save.

* Left-to-Right Paragraph switching - if an editor is working on both
english and arabic stories, the ability to switch the interface to have
left-to-right and right-to-left import is needed. Input channels isn't
appropriate here as the ability to have multiple people working on
different languages at the same time is needed.

* Option to show URI on search results page

* Add permissions for creating new keywords (for cases where you want to
enforce a fixed set of keywords)

* Make sure everywhere where a category is entered, it can be done via
ajax auto-complete.

* Option to include category information when uploading media

We'll follow up to this and post implementation specifics for the bigger
features to see what everyone thinks and see if it can get committed into
source.

Cheers,

Alex

--
Alex Krohn <alex [at] gossamer-threads>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806

david at kineticode

Jan 30, 2009, 9:23 AM

Post #2 of 12 (3268 views)
Permalink

Re: bricolage enhancements [In reply to]

On Jan 28, 2009, at 10:13 PM, Alex Krohn wrote:

> * Editable Preview - when you have a story checked out and then
> preview
> it, we want to add the ability to be able to click in any paragraph
> block and have the text editable. This allows for quick typo fixes and
> other minor text changes to be made while previewing a document.

+1 Based on our discussion a few months ago, I think that this will be
a relatively straight-forward project.

> * Copy and Paste - beside each element, we want to add a copy feature
> that will copy the element into a copy buffer. Then on the existing
> story or on a new story, we will adjust the insert element menu to
> also
> include a Paste option (assuming the element currently in the copy
> buffer is allowed).

+1 Nice idea! Might as well have a “Cut” as well as “Copy.”

> * Word Import - this may end up in contrib as we aren't sure how
> generic
> it can be made. The goal is that on the new story page, you will be
> able
> to upload a word file created with a predefined style sheet. The word
> file will be parsed and the meta info pulled from the document
> properties and the elements created from the document itself giving
> you
> a pre-populated story that you can then tweak and save.

I could see this going into the UI, especially if the code behind the
scenes is pluggable, so that future devs could do the same thing for
Pages, WordPerfect, Excel, PDF, whatever documents.

> * Left-to-Right Paragraph switching - if an editor is working on both
> english and arabic stories, the ability to switch the interface to
> have
> left-to-right and right-to-left import is needed. Input channels isn't
> appropriate here as the ability to have multiple people working on
> different languages at the same time is needed.

I'm not sure how input channels fails to address this issue. I mean, a
button to trigger some JS to flip all fields from rtl to ltr and back
is a simple task, so maybe that gets you want you need and input
channels are just overkill. But that's not what you said.

> * Option to show URI on search results page

IIRC, if you hover over a story, I think that the URI appears as a
part of the Bricolage URI in the status bar of your browser.

> * Add permissions for creating new keywords (for cases where you
> want to
> enforce a fixed set of keywords)

Sure.

> * Make sure everywhere where a category is entered, it can be done via
> ajax auto-complete.

We're gradually nailing these down now. It's technically a bug in
1.11.x that it's not done everywhere yet.

> * Option to include category information when uploading media

Don't understand this one. Can you say more?

> We'll follow up to this and post implementation specifics for the
> bigger
> features to see what everyone thinks and see if it can get committed
> into
> source.

+1

Nice, thanks for pushing Bricolage forward in 2009, Alex.

Best,

David

alex at gossamer-threads

Feb 5, 2009, 1:36 PM

Post #3 of 12 (3233 views)
Permalink

Re: bricolage enhancements [In reply to]

Hi David,

Sorry about the late reply here, we just moved offices and this week has
just been crazy. =)

Thanks for your feedback on things, very helpful!

> > * Copy and Paste - beside each element, we want to add a copy feature
> > that will copy the element into a copy buffer. Then on the existing
> > story or on a new story, we will adjust the insert element menu to
> > also include a Paste option (assuming the element currently in the copy
> > buffer is allowed).
>
> +1 Nice idea! Might as well have a �Cut� as well as �Copy.�

I think Cut gets a bit more tricky as then you are deleting an element
on a story that you may no longer have checked out or access to. Need to
think about that a bit more.

> > * Left-to-Right Paragraph switching - if an editor is working on both
> > english and arabic stories, the ability to switch the interface to
> > have left-to-right and right-to-left import is needed. Input channels isn't
> > appropriate here as the ability to have multiple people working on
> > different languages at the same time is needed.
>
> I'm not sure how input channels fails to address this issue. I mean, a
> button to trigger some JS to flip all fields from rtl to ltr and back
> is a simple task, so maybe that gets you want you need and input
> channels are just overkill. But that's not what you said.

Yup, re-reading that I was mixing a few ideas into one paragraph.
Basically input channels wasn't suitable for handling languages due to
the lack of multiple editors to work on the same document at the same
time (i.e. one person work on a french translation and another with an arabic
one). Since input channels were not suitable, we can't determine the
language of the story based on an input channel, and thus can't tailor
the UI based on the input.

So given that, we are looking at adding the ability to let the editor
flip the ui based on the story he is working on.

> > * Option to show URI on search results page
>
> IIRC, if you hover over a story, I think that the URI appears as a
> part of the Bricolage URI in the status bar of your browser.

Yes, the problem is that when a search page gives back 50 results,
having to hover over each link isn't practical. In the WHO case, there
is a lot of useful information in identifying a story in the URL (often
more so then the actual title).

> > * Option to include category information when uploading media
>
> Don't understand this one. Can you say more?

I'll get specifics here, but the short version is there is a place where
when uploading an image, it defaults to the same category as the story
rather then letting you specifiy a specific category. I'll post more
with an exact scenerio.

Cheers,

Alex

--
Alex Krohn <alex [at] gossamer-threads>

david at kineticode

Feb 5, 2009, 5:05 PM

Post #4 of 12 (3237 views)
Permalink

Re: bricolage enhancements [In reply to]

On Feb 5, 2009, at 1:36 PM, Alex Krohn wrote:

> Sorry about the late reply here, we just moved offices and this week
> has
> just been crazy. =)

I'll bet!

> Thanks for your feedback on things, very helpful!

Glad to help.

>> +1 Nice idea! Might as well have a �Cut� as well as �Copy.�
>
> I think Cut gets a bit more tricky as then you are deleting an element
> on a story that you may no longer have checked out or access to.
> Need to
> think about that a bit more.

�Cut� would only be available when the user has the story checked-out.
That'll be a pretty simple thing to check.

> Yup, re-reading that I was mixing a few ideas into one paragraph.
> Basically input channels wasn't suitable for handling languages due to
> the lack of multiple editors to work on the same document at the same
> time (i.e. one person work on a french translation and another with
> an arabic
> one). Since input channels were not suitable, we can't determine the
> language of the story based on an input channel, and thus can't tailor
> the UI based on the input.
>
> So given that, we are looking at adding the ability to let the editor
> flip the ui based on the story he is working on.

Ah, gotcha. So to have editors working on the �same document� at the
same time, WHO will clone stories, yes? In that case, a flip button of
some kind (enabled by a preference?) would be useful.

> Yes, the problem is that when a search page gives back 50 results,
> having to hover over each link isn't practical. In the WHO case, there
> is a lot of useful information in identifying a story in the URL
> (often
> more so then the actual title).

Understood.

> I'll get specifics here, but the short version is there is a place
> where
> when uploading an image, it defaults to the same category as the story
> rather then letting you specifiy a specific category. I'll post more
> with an exact scenerio.

Yes please do. At this point, when you upload a media document from a
related media element, it's automatically put into the same category
as the story. But then you're also taken to the media document
profile, where you can change it.

Best,

David

rolfm at denison

Feb 6, 2009, 3:18 PM

Post #5 of 12 (3227 views)
Permalink

Re: bricolage enhancements [In reply to]

My 2�. . .

On Jan 29, 2009, at 1:13 AM, Alex Krohn wrote:

> * Editable Preview - when you have a story checked out and then
> preview
> it, we want to add the ability to be able to click in any paragraph
> block and have the text editable. This allows for quick typo fixes and
> other minor text changes to be made while previewing a document.

How will this work for those installations that preview to another
server and don't use the Bricolage instance to display previews?

> * Copy and Paste - beside each element, we want to add a copy feature
> that will copy the element into a copy buffer. Then on the existing
> story or on a new story, we will adjust the insert element menu to
> also
> include a Paste option (assuming the element currently in the copy
> buffer is allowed).

I'll be curious to see how this works from a usability standpoint.

> * Word Import

This could potentially be good, depending on the implementation.

> * Left-to-Right Paragraph switching

Not a concern of ours, but I can see where it would be useful.

> * Option to show URI on search results page

Yeah, I like this.

> * Add permissions for creating new keywords

Sure, why not?

> * Make sure everywhere where a category is entered, it can be done via
> ajax auto-complete.

With the caveat that there are some nasty bugs out there with the
autocomplete that should be fixed. #1390 in particular, but I'm
pretty sure the final fix for #1355 hasn't been committed.

> * Option to include category information when uploading media

I'd also like to see more specifics on this.

The only thing I'll add is that with any features we're adding, we
should think about how that will impact the interface as a whole, and
where we want the interface to be in the next major release after 2.0.
As a general principle, we need to reduce UI complexity, make viewing
the more advanced features optional in some cases, and continue to
make changes that streamline publishing within the workflow model.
Now that's my take and my take only, but I think it's good to keep in
mind.

Thanks for being willing to take all this on!

-Matt

adrian at gossamer-threads

Feb 6, 2009, 6:55 PM

Post #6 of 12 (3220 views)
Permalink

Re: bricolage enhancements [In reply to]

Matthew Rolf wrote:
>
>> * Editable Preview - when you have a story checked out and then preview
>> it, we want to add the ability to be able to click in any paragraph
>> block and have the text editable. This allows for quick typo fixes and
>> other minor text changes to be made while previewing a document.
>
> How will this work for those installations that preview to another
> server and don't use the Bricolage instance to display previews?

I commented on this in my last e-mail. Essentially you need the preview
server to be:
1) On the same domain (eg. preview.bricolage.cc, bricolage.cc)
2) Set up rewrite rules on the preview server to redirect the ajax
request to the application server
3) Modify Bricolage's cookies to send them do .example.com so that they
get sent to the preview server as well.

I believe that should get around the browser's same origin security
restrictions.

>> * Option to show URI on search results page
>
> Yeah, I like this.

This is a simple change to comp/workflow/manager/dhandler. However,
would it be better put which columns to show as a configuration option?
I'm not sure what Bricolage's policy is on adding options to the
configuration (or even as a user option). The same would probably be
done for template and media search results.

Adrian

david at kineticode

Feb 9, 2009, 2:18 PM

Post #7 of 12 (3209 views)
Permalink

Re: bricolage enhancements [In reply to]

On Feb 6, 2009, at 6:55 PM, Adrian Yee wrote:

>>> * Option to show URI on search results page
>> Yeah, I like this.
>
> This is a simple change to comp/workflow/manager/dhandler. However,
> would it be better put which columns to show as a configuration
> option? I'm not sure what Bricolage's policy is on adding options
> to the configuration (or even as a user option). The same would
> probably be done for template and media search results.

+1 to make it a preference.

Best,

David

bret at pectopah

Feb 9, 2009, 2:24 PM

Post #8 of 12 (3206 views)
Permalink

Re: bricolage enhancements [In reply to]

Hi everybody,

Here's a line from Alex Krohn about WHO enhancements for Bricolage:

> * Left-to-Right Paragraph switching - if an editor is working on both
> english and arabic stories, the ability to switch the interface to
> have
> left-to-right and right-to-left import is needed. Input channels isn't
> appropriate here as the ability to have multiple people working on
> different languages at the same time is needed.

As it turns out, we need something similar for a site we're building
now, which will have up to five languages per story.

Rather than full-blown input channels, we're using subelements for each
language that isn't English. So, if you want to add a Spanish version to
a story, you add a "Spanish profile" subelement and fill it in.

What I would like is the ability to define individual fields as LTR or
RTL when I'm defining them. That way I could all the fields in the
"Arabic Profile" subelement would be LTR by default.

Greg and I just had a conversation about toggling as well, so that in
the element type profile, you could define a default direction for each
input box or textarea, and you could also choose whether the UI should
offer a "switch direction" toggle link alongside the field. I think
that's a good idea.

Anyway, here's a quick recap of what we have in mind:

1. Add "default direction" selector to the field profile for textareas
and input boxes.
2. Add "show direction toggle" selector to the field profile for
textareas and input boxes.
3. Leave WYSIWYGs alone. Xinha has built-in direction togglers that work
just fine.

Alex, would this meet your needs as well? (If it does, we'll just go
ahead and build it, and you can help yourselves to the patch.)

Thanks, and talk to you soon,

Bret

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

alex at gossamer-threads

Feb 10, 2009, 6:20 PM

Post #9 of 12 (3188 views)
Permalink

Re: bricolage enhancements [In reply to]

Hi Bret,

> As it turns out, we need something similar for a site we're building
> now, which will have up to five languages per story.

The WHO model is different, where each language is a separate story.

> What I would like is the ability to define individual fields as LTR or
> RTL when I'm defining them. That way I could all the fields in the
> "Arabic Profile" subelement would be LTR by default.

I don't think this would work in the WHO model as that would mean using
a separate element for each language.

> Alex, would this meet your needs as well? (If it does, we'll just go
> ahead and build it, and you can help yourselves to the patch.)

No, I don't think so unfortunately due to the fundamental difference
with how languages are being handled. I think in your case input
channels might make sense and be the better way to approach it. The
reason it wasn't suitable for WHO is the fact that you could only have
the story checked out at one time (and often stories would go out to
different editors/translators at the same time).

Cheers,

Alex

--
Alex Krohn <alex [at] gossamer-threads>

david at kineticode

Feb 10, 2009, 10:14 PM

Post #10 of 12 (3175 views)
Permalink

Re: bricolage enhancements [In reply to]

On Feb 10, 2009, at 6:20 PM, Alex Krohn wrote:

>> What I would like is the ability to define individual fields as LTR
>> or
>> RTL when I'm defining them. That way I could all the fields in the
>> "Arabic Profile" subelement would be LTR by default.
>
> I don't think this would work in the WHO model as that would mean
> using
> a separate element for each language.

Or a separate input channel in one story. That is rather the point of
input channels.

>> Alex, would this meet your needs as well? (If it does, we'll just go
>> ahead and build it, and you can help yourselves to the patch.)
>
> No, I don't think so unfortunately due to the fundamental difference
> with how languages are being handled. I think in your case input
> channels might make sense and be the better way to approach it. The
> reason it wasn't suitable for WHO is the fact that you could only have
> the story checked out at one time (and often stories would go out to
> different editors/translators at the same time).

In the beginning, we wanted to support concurrent checkout. That would
be nice to get at some point, though then someone has to figure out
how to handle reconciliation of conflicts.

Best,

David

lannings at who

Feb 12, 2009, 2:27 AM

Post #11 of 12 (3166 views)
Permalink

Re: bricolage enhancements [In reply to]

On Tue, 10 Feb 2009, David E. Wheeler wrote:
> In the beginning, we wanted to support concurrent checkout. That would be
> nice to get at some point, though then someone has to figure out how to
> handle reconciliation of conflicts.

I'm not sure that "concurrent checkout" makes sense.
What is the point of checking something out,
if not to block others from working on it?
In that case, I think it'd be better to get rid of checkouts
and have reconciliation of conflicts on the level of
elements (and eventually input channels).

(Go git?)

david at kineticode

Feb 12, 2009, 9:16 AM

Post #12 of 12 (3153 views)
Permalink

Re: bricolage enhancements [In reply to]

On Feb 12, 2009, at 2:27 AM, Scott Lanning wrote:

> I'm not sure that "concurrent checkout" makes sense.
> What is the point of checking something out,
> if not to block others from working on it?
> In that case, I think it'd be better to get rid of checkouts
> and have reconciliation of conflicts on the level of
> elements (and eventually input channels).

Yep, agreed. The idea of checkout at that point would just be that it
appears on your workspace.

David

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads