On Feb 19, 2014 2:28 AM, "Aaron J. Seigo&qu= ot; <aseigo@kde.org> 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/BalooArticle cou= ld

from the article, i get the following key points:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * stability
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * performance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * ease of use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * 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 fl= ow
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 l= ike:

Introduction
Using Baloo (=E2=80=9DBaloo for users=E2=80=9D)
Developing with Baloo (second half of =E2=80=9Cabout baloo=E2=80=9D)
The design behind Baloo (first half of =E2=80=9Cabout 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 =E2=80=9Cusing=E2=80=9D from =E2=80=9Cdeveloping=E2=80=9D more c= learly may also help the
readability a bit; e.g. in =E2=80=9Cbaloo for users=E2=80=9D right now ther= e 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=E2=80=99s not really relevant to usage right now that it can= be more
easily added to in future ...

I suggest dropping the entire =E2=80=9CWhy change Nepomuk=E2=80=9D section = (regardless of what
happens with naming): it=E2=80=99s technical, dry and negative. I don=E2=80= =99t know how many
people in the target audience will care about RDF and how it works, for
instance. The "Making Nepomuk Usable=E2=80=9D sub-section could be re-= purposed as an
introduction to a =E2=80=9Cdesign behind baloo=E2=80=9D section. I would en= tirely 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<= br> (Application Programming Interfaces, glue for integration) and widgets (lik= e
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 reliab= le.

Even after all this work, paint points remained. In particular, the storage=
system used in Nepomuk continued to present performance challenges that wer= e
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=E2=80=99t necessary to understand the message and turns it all= into a
nice story of =E2=80=9Cthe Nepomuk developers listened and worked hard to m= eet 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.