Requirements for extension site

classic Classic list List threaded Threaded
8 messages Options
htietze htietze
Reply | Threaded
Open this post in threaded view
|

Requirements for extension site

Hi all,

before (or maybe in parallel to) checking whether Askbot is usable as a
platform for LibreOffice extensions we should clearly define what
requirements are needed. There is a very old document circulating In the
other thread, which _describes_ the state of the current site. Based on
these insights we created a new document for a new hosting platform. The
document is shared on
https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
discussion.

Cheers,

Heiko


--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy
Bjoern Michaelsen-3 Bjoern Michaelsen-3
Reply | Threaded
Open this post in threaded view
|

Re: Requirements for extension site

Hi Heiko,

On Sat, Oct 13, 2018 at 09:52:01AM +0200, Heiko Tietze wrote:
> Based on these insights we created a new document for a new hosting platform.
> The document is shared on
> https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
> discussion.

Thanks for sharing that.

That looks indeed like a very promising approach to finding the core functionality
that is needed.

Best,

Bjoern

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy

htietze htietze
Reply | Threaded
Open this post in threaded view
|

Re: Requirements for extension site

After reading through the comments on the other thread I'd like to
outline a scenario: We do provide access to Firefox Personas (Tools >
Options > Personalization) (being reworked currently) where the user can
place an image in the background of the toolbar/notebookbar. Those
themes are a great success with gazillions of contributions. It's a bit
embarrasing that we have to access data from another project and could
host those images ourself.

As a user you probably don't know about this option to extend the
program. So we should give access to it from the place where it is
listed. You want to browse, sort and filter by different kind of
attributes, mark favorites, load.

As creator of, let's say the pink theme for best integration into the
dreamland desktop, you have no idea about sharing data, meaning the
upload must be easy. There are a couple of settings needed such as
license where a wizard like guidance makes sense. But in the end as less
info as possible to make the upload a breeze.

Some "cornercases" (actually secondary requirements) have to be
considered. Our current platform requires maintainers to state the
compatibility with every new release (which is again a very code
oriented view). And maintainer likely don't want to be in charge
forever. My take here is to switch to a community based approach and
flag non-working extensions as outdated/orphaned. Communication between
creator/maintainer and user is essential in open source. Maybe the
dreamland has some unicorns that should be added.

Hope all this becomes clear with the shared document and the mockups.

Am 13-Oct-18 um 10:14 schrieb Bjoern Michaelsen:

> Hi Heiko,
>
> On Sat, Oct 13, 2018 at 09:52:01AM +0200, Heiko Tietze wrote:
>> Based on these insights we created a new document for a new hosting platform.
>> The document is shared on
>> https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
>> discussion.
> Thanks for sharing that.
>
> That looks indeed like a very promising approach to finding the core functionality
> that is needed.
>
> Best,
>
> Bjoern


--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy
Cor Nouws Cor Nouws
Reply | Threaded
Open this post in threaded view
|

Re: Requirements for extension site

In reply to this post by htietze
Heiko Tietze wrote on 13-10-18 09:52:

> document is shared on
> https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
> discussion.

Thanks, I added some comments, suggestions. And text (Ctrl+Shft+E starts
/ stops tracking changes ;) )
I didn't (yet) look in the mail from Andreas_k (1) to add/compare but
think the set we are looking for, can be nice and basic.

Cheers,
Cor


1)  https://listarchives.libreoffice.org/global/design/msg08889.html

--
Cor Nouws
GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28  A038 E49D 7365 B134 80A6
- vrijwilliger https://nl.libreoffice.org
- volunteer https://www.libreoffice.org
- Member Board The Document Foundation
- http://www.nouenoff.nl / https://www.mijncloudoffice.nl

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy
kainz.a kainz.a
Reply | Threaded
Open this post in threaded view
|

Re: Requirements for extension site

For me the next step would be to get feedback how will help to update the
extension page.

I will help. My skills are design stuff. I know css and php.

Cor Nouws <[hidden email]> schrieb am Sa., 13. Okt. 2018, 11:13:

> Heiko Tietze wrote on 13-10-18 09:52:
>
> > document is shared on
> > https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
> > discussion.
>
> Thanks, I added some comments, suggestions. And text (Ctrl+Shft+E starts
> / stops tracking changes ;) )
> I didn't (yet) look in the mail from Andreas_k (1) to add/compare but
> think the set we are looking for, can be nice and basic.
>
> Cheers,
> Cor
>
>
> 1)  https://listarchives.libreoffice.org/global/design/msg08889.html
>
> --
> Cor Nouws
> GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28  A038 E49D 7365 B134 80A6
> - vrijwilliger https://nl.libreoffice.org
> - volunteer https://www.libreoffice.org
> - Member Board The Document Foundation
> - http://www.nouenoff.nl / https://www.mijncloudoffice.nl
>
> --
> To unsubscribe e-mail to: [hidden email]
> Problems?
> https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
> List archive: https://listarchives.libreoffice.org/global/design/
> Privacy Policy: https://www.documentfoundation.org/privacy
>

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy
toki toki
Reply | Threaded
Open this post in threaded view
|

Re: Requirements for extension site

In reply to this post by Cor Nouws
On 10/13/18 9:13 AM, Cor Nouws wrote:
> Thanks, I added some comments, suggestions. And text (Ctrl+Shft+E starts

Picking up a comment made by Heiko:
«If the release would be a property of the project we could remove a lot
of needed interactions. Drawback is that only one release is stored.
Does that make sense?»

This raises the idea that perhaps extensions.git.libreoffice.org should
be a thing. A self-hosted git repository.
Bot-driven, it would clone the developer's site, build the extension,
and create the catalogue.

Lot more thinking needs to be done about how to construct it, write the
automation bots, etc.

Still doesn't solve the issue of "not enough volunteers".
Also means yet another piece of software that TDF has to look after.

jonathon






--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy
toki toki
Reply | Threaded
Open this post in threaded view
|

Re: Requirements for extension site

In reply to this post by htietze
On 10/13/18 7:52 AM, Heiko Tietze wrote:

> these insights we created a new document for a new hosting platform. The
> document is shared on
> https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
> discussion.

Responding here, cause it is easier for me.
(Not sure why the site let me download it once, without logging in, but
when I tried to downloading it from my main system, it insisted on a
password. And of course I failed the ReCapcha.)

(For starters, why on earth is everything "default style"?  All markup
done manually‽‽‽ )

>If an extension is broken would be reported by users not the author.

Some authors are pro-active, in determining if their extension is broken
in a new version of LibO.

There are also edge cases where an extension may run:
* Only on one platform; Eg: Windows, but not Linux or Mac OS X. Android,
but not Linux, Windows, or Mac OS X, etc.
* Only with a specific language User Interface.  IIRC, JILT is an example;
* RUn only when another extension is also installed.  By way of example,
CMath requires CMathCAS to be installed.

>Most of those are already in the metadata of an extension.

Neither the current collected set of meta data, nor the set proposed
within the document include every datapoint from Dublin Core, nor of its
successor. If metadata is to be provided, at least do Dublin Core, if
not its successor.

>homepage. Is this really needed?

Yes.
It isn't uncommon for developer/creator to use something other than
their email address for:
* providing alpha/beta versions of extensions/templates;
* feedback mechanism, be it a mailing list, or bugzilla or something else;
* Additional documentation;

For when the extension, or template appears to be abandoned, the
homepage as oft as not:
* states that the extension is no longer being developed, maintained, or
supported;
* has switched to commercial distribution and support only;
* However, there is at least one vendor who declaims all knowledge of a
LibO extension for their product;

>Categories: Would strongly recommend to change this into single
selection of category (dictionary, clipart, color palette...) with
single selection and scope (Writer, Calc..) with multi selection.

In essence I agree.
There are a couple of corner cases, but they can be solved as they come
up. Off hand, the only three examples I can think of, are an Accounting
package, and a Project Management Package, both of which utilise Base,
Calc, and Write, and a Business Startup package, which either utilises
Calc, Impress, and Write, or just Impress and Calc.

No extension may have more than one top level category.
Do templates delivered as an extension belong under "extension" or
"template"? Examples can be found at
http://sourceforge.net/projects/ooop/files/Extension/2.4.0.4/ .

I've seen reference to a corporate house style that appear to include
colour palettes, dictionaries, fonts, and templates for Write, Calc,
Impress, Draw, Math, and Base. If anything along those lines escapes
from their corporate guard, simply make "House Style" a top level category.

>Logo:
As a user, I like seeing the logo, because it makes it more apparent if
I found the extensions/template I want.
By way of example, there are two extensions that assist with Greek
characters _Ancient Greek_ and Polytonic Greek_.  In a pinch, they sort
of overlap, but for writing in Biblical Greek, the former is slightly
more functional. Telling a Bible Study class that they want the
extension with a red logo makes it far more likely that everybody in the
class will get the "correct" extension.
On the flipside, both Simplified Chinese Punctuation bar, and
Traditional Chinese punctuation bar use the same logo.   Really hard to
differentiate between the two, by logo alone.
Furthermore, as oft as note, taht logo is the identifier on whichever
toolbar it places itself upon.

>Extension most certainly contain a description of themselves.

They do, but as oft as not, that description is inadequate. By way of
example:
* Which versions of GedCom does the GedCom Import extension support?
* Which playback devices does the Transcriber extension support?
* Which Braille printers does ODT2Braille support? (Ignoring that that
extension appears to be abandoned.)

>If the release would be a property of the project we could remove a lot
of needed interactions.

At the expense of requiring yet more volunteers, and cash, perhaps
setting up extensions.git.libreoffice.org that is used exclusively to
create extensions, templates, palettes, fonts, clip-art, etc. that is
used by LibO should be done. This way, if the item has the appropriate
license, a LibO volunteer could take over maintaining the item.  Umm,
maybe not extensions, per se, but certainly templates, sound-effects,
and all the other things that are deliverable as .oxt files.
Either a bot, or an individual could walk through each project, flagging
it for missing items ---- license.md, readme.md, metadata.md, etc.

>Publishing Data, Expiration Date, Why?

Publishing date can give one an idea of which version of LibO it should
work with. Expiration date, is because sometimes an external API that
the extension relies, closes, with an announcement made months, or even
years before. I'd give an example, but thanks to the miracle of
simultaneous hard drive failure, I can't. (In backing up my hard drive,
both drives simultaneously failed, thereby losing all of the extensions,
and notes I have on them, for roughly the past decade. (Four TB flew
into the digital aether. ) A similar thing happened when I previously
tried, and failed to back up a storage drive. That time I lost my notes
from circa 2001 through circa 2010.)

>Categorization: Language: single, multi. Why should the release differ
from the project.

After I've drawn a mockup, and written dummy code that demonstrates how
it works, I'll submit an RFE to redesign/redo the entire language
selection. Rounding, there are 1.07E+010 possible combinations.
First step is to make it easy to jump from any combination to any other
combination, in three or less hops, whilst providing no more than 7
choices per hop.

Anyway, getting back to the topic, there are templates for languages
that are not found in any of the ISO 639 # lists, that use writing
systems not found in any variant of ISO 15924 # lists.  If those were to
be uploaded to the template, or extension side of things, they would, by
necessity, different from the project.

>Totally unclear to me. Add new > "Extension linked release" and
"Extension release".

This gets back to Extension s designed for use with specific templates.
If you don't have the template, the extension won't work, and if you
don't have the extension, the template won't work.  There are two or
three combinations in either the LibO or AOo repository. (The
aforementioned Accounting, Project Management, and Business Startup
packages could be squeezed into this group, as an example, but they are
a slightly different case.)

> publish, re-release, and hide releases

This is when there is an issue with something within the item, that can
probably be easily remedied. By way of example, a DMCA take down notice.

>Adrian wants to cut, copy/paste, delete and rename a release. Don't
understand this feature. Is it about the additional info?

This mainly has to do with forks, but can occasionally be due to
internal mis-naming.

Also, sometimes as in my _Graphology Templates 0.6_ release, I had half
a dozen individual templates, as well as one very big template. Being
able to cut/paste/rename can be useful. However, this type of thing is
probably better done on a development site, rather than the distribution
point.

####

My main rant is for extensions that neither identify themselves once
installed, nor provide any clues as to what functionality they bring to
the table.

For some extensions, once installed, there is nothing to tell what they
are supposed to do, unless one plays with them.
My pet peeve is extensions that create their own toolbar, and call it
_Add-On 2_ (Anaphraseus is one culprit. This gets into design flaws made
by extension creators.)




--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy
htietze htietze
Reply | Threaded
Open this post in threaded view
|

Re: Requirements for extension site

On 10/16/18 12:05 AM, toki wrote:
> ...

Many thanks for your comments; me needs some time to understand everything in detail. Just two general remarks: The document consists of a copy from the old discussion taken from GDrive to our LOOL instance (not all comments are mine) and a new part on top thinking ahead. My idea is to make the platform as simple as possible with the least effort for maintainers. And I have primarily non-code contributions in mind, like color palettes, images, icons etc. (that I would like to see improve). Of course we have to cover also a the Git-like workflow and your idea is tempting.

Cheers,
Heiko


--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy