Re: Article about Baloo

I really like this. A lot.
On Feb 19, 2014 2:28 AM, "Aaron J. Seigo" <[email protected]> wrote:

> On Monday, February 17, 2014 15:43:29 Jos Poortvliet wrote:
> > It would be great if the draft on https://notes.kde.org/p/BalooArticlecould
>
> from the article, i get the following key points:
>
>         * stability
>         * performance
>         * ease of use
>         * bright future
>
> Those are great points, and the article starts off strongly. The content in
> general is great imho. The only thing that leaped out at me was that the
> flow
> meanders from design to developers to users to developers to migration to
> developers ...
>
> What would you think about simplifying the flow a bit so that it goes sth
> like:
>
> Introduction
> Using Baloo (”Baloo for users”)
> Developing with Baloo (second half of “about baloo”)
> The design behind Baloo (first half of “about baloo")
> Migrating to Baloo (4.13, migration tool, KF5...)
>
> That way people get told what it does for them / how it makes their life
> better before getting into the details of the design.
>
> Separating “using” from “developing” more clearly may also help the
> readability a bit; e.g. in “baloo for users” right now there is this
> sentence:
>
> "The simplicity of the design will not only reduce failures, but will also
> make it easier for current and new contributors to add and improve
> functionality."
>
> While true, it’s not really relevant to usage right now that it can be more
> easily added to in future ...
>
> I suggest dropping the entire “Why change Nepomuk” section (regardless of
> what
> happens with naming): it’s technical, dry and negative. I don’t know how
> many
> people in the target audience will care about RDF and how it works, for
> instance. The "Making Nepomuk Usable” sub-section could be re-purposed as
> an
> introduction to a “design behind baloo” section. I would entirely avoid
> criticizing the outcome of the research project.
>
> Perhaps something along the lines of:
>
> Since its inception, Nepomuk developers received and digested a lot of
> feedback. Application developers requested and received easier to use APIs
> (Application Programming Interfaces, glue for integration) and widgets
> (like
> the star rating or a tagging dialog). Users clearly requested increased
> stability and performance. Much work was put into improving the speed of
> indexing, keeping it out of the way of users and making Nepomuk more
> reliable.
>
> Even after all this work, paint points remained. In particular, the storage
> system used in Nepomuk continued to present performance challenges that
> were
> unresolvable on desktop and mobile systems.
>
> To address this, the developers took a step back to look at how Nepomuk was
> being used in practice. The major use-cases they found are:
>
> <...etc...>
>
>
> This is a lot less negative about Nepomuk, skips a lot of technical detail
> tat
> probably isn’t necessary to understand the message and turns it all into a
> nice story of “the Nepomuk developers listened and worked hard to meet the
> needs being communicated to them."
>
> --
> Aaron J. Seigo
>
> _______________________________________________
> This message is from the kde-promo mailing list.
>
> Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set
> digest on or temporarily stop your subscription.


_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription.