[Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature

[Aleksey Lim]

On Sun, Dec 06, 2009 at 11:56:09PM +0000, Gary C Martin wrote:
> On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote:
> 
> > 2009/11/27 Aleksey Lim <alsroot at member.fsf.org>:
> >> On Fri, Nov 27, 2009 at 06:13:55AM +0000, Aleksey Lim wrote:
> >>> Hi all,
> >>> 
> >>> Want to know what people think about Journal Plugins feature[1]
> >>> and particularly that design team think about UI changes[2] involved
> >>> in this feature.
> >>> 
> >>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#
> >>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes
> >> 
> >> I tweaked "Benefit to Sugar" section a bit
> >> 
> >> * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea.
> >> * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar
> >> * encourage developers create new view for different purposes(books, media etc.)
> >> * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment
> >> * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them)
> >> * shared bookmarks is more powerful and useful method of network sharing(in comparing with "Send to" option)
> > 
> > Can anyway relate these benefits from actual requests from deployments?
> > 
> > I think this is something that would be good to do in Sugar at some
> > point, but I'm not convinced we are yet in the best moment for that.
> 
> 
> I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters.

The core idea of plugins is exactly to avoid situation when we have to
release fat UI change set, plugins let us decentralize existed scheme
when entirely sugar design(not only UI) depends on what core team
thinks. We just provide usable toolset developers cold use to implement
what they think.

[1] proposes UI changes in [2] but plugins API could be implemented w/o
any UI changes at all - user will see the same Journal(but it will be
Journal plugin). The idea is let developers make plugin out of sucrose
release cycle, yeah developers could do it in pure activities(but see
[3]) and even out of sugar at all, but imho it will be useful(in all
cases, not only technical) to initiate/support/organize such process
from core.

[3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description

-- 
Aleksey