[PD] deken install user experience

Thu Jun 9 10:33:07 CEST 2016

On Wed, 2016-06-08 at 14:00 +0200, IOhannes m zmoelnig wrote:
> On 2016-06-08 12:09, Hans-Christoph Steiner wrote:
> > 
> > 
> > I'd
> > like to find a little time to contribute to it, to smooth out the
> > user
> cool.
> welcome back.
> 
> > 
> > 
> > * hide all incompatible library version by default (e.g. hide OSX
> > and
> > Windows versions on GNU/Linux)
> this is what we are currently doing.
> all incompatible versions are sorted after the compatible ones, and
> (more importantly) they are greyed out.
> they are still selectable though.

Sorry if I missed this, but what is the point of displaying
incompatible (wrong arch, wrong platform) Deken packages? What would be
harmed if they'd be hidden completely? I fail to see the advantage of
having the possibility of downloading a package of wrong arch/platform.

> > * by default, install into user's pd externals folder without any
> > prompt
> > (~/pd-externals, etc)
> hmm, well: there has been a lot of discussion on this list about
> which
> approach should be taken.
> 
> a short (probably biased) recap (but you'll find more detailed
> reasoning
> in the archives):
> - originally, deken would try to download/install into the externals
> folder (as your suggestion). it would even try to create this folder,
> in
> case it was not there yet.
> this was rejected, as many people very much dislike applications
> creating folders in their home directory (~/pd-externals).
> - a second iteration did the same, but without trying to create any
> directories. if no writable folder was found, deken would prompt the
> user for a target directory)
> this was rejected because people have very different opinions about
> the
> scope of downloaded externals (per-user, per-project, per-pd).
> - a third iteration added a big button to manually set the directory
> before downloading stuff (and otherwise would try the standard search
> paths first).
> this was rejected because it was not obvious. (which only shows that
> i'm
> a bad UI designer)
> - the fourth iteration went for simplicity and prompted the user
> where
> to install.
> 
> currently, Pd-vanilla uses the 4th iteration, wheras deken upstream
> still uses the 3rd iteration.

And current behavior (4th iteration) is still unlucky. Retrospectively,
my conclusion is it is a flawed approach to have a discussion with
mostly expert users and try to respect their different workflows. The
result seems to disregard the needs of newcomers and users that don't
want to get bothered with anything that is not a "standard" workflow.
First of all, the tool should just _do_ what is sensible, since the
user doesn't necessarily know what is sensible. Prompting for a
download directory can already be confusing. To tell from my own
experience, on one box the directory ~/.local/lib/pd/extra already
existed and Deken sensibly proposed to install libraries there. On
another box there was no ~/.local/lib/pd/extra and Deken proposed my
home directory as install dir! What are inexperienced people supposed
to do with that?! There is no point ever in install libraries directly
to my home. Every other behavior I can imagine is better than proposing
my home directory as library install path. Of course, even
inexperienced users don't want to install their externals in their home
so they just make something up, like ~/pd/extra. However, ~/pd/extra is
not a default search path and whatever they try to run (for instance,
they downloaded netpd and netpd [declare]s all necessary libraries) and
it will fail, because [delcare]d stuff needs to be in any of the
standard search paths. The users spend quite some time investigating
the issue of not loaded libraries, and  since they are not aware of the
magic of default search paths (how should they know, when they do not
read the pd mailing list and Deken doesn't even give a hint of a
sensible install path?) they will figure out you can specify search
paths in the Pd preferences. So they go through the trouble of adding
all libraries in the non-default location ~/pd/extra/ and they finally
can successfully run the patch. However, they achieved it by adapting
their preferences to the patch they want to run! That's so much not
what we want people think they have to do, changing their preferences
for whatever project they run! 

In my ideal world, I write a Pd project, make sure it properly declares
what it needs and then people who want to run my project find a list in
the documentation with the required externals (with no further
explanation how to do that and where to install). After installing the
externals from the list, my pd project runs on their box and is able to
successfully load the libraries. We're not there yet, see above.

Even for experienced users who want to support their special workflow,
the prompt for a directory doesn't make sense in my opinion. I think
someone mentioned that they have several local installs of Pure Data on
their box and they host different sets of libraries for each Pd
installation. Even in this case, the prompt is annoying. I rather would
edit the deken-plugin.cnf of each included deken-plugin and override
the default search path (~/.local/lib/pd/extra) with '<my-local-pd-for-
experimenting>/extra/'. What I'm trying to say is that experienced
users know already about search paths and they're probably much more
comfortable with editing a cnf file than having to deal with a GUI file
browser each time they download something. So I'm not seeing whom the
browser prompt actually is supposed to help.

Another thing, that I feel was a crucial part in the reason for having
so many iterations, is that people complained about Pd creating a
directory in the user's home without asking (~/pd-externals). While I
understand that concern, the reason to address this just vanished with
the switch to ~/.local/lib/pd/extra. pd-externals was annoying, but I
doubt anybody would ever complain about Pd creating
~/.local/lib/pd/extra, so ___pplleeaazzee__ let's  Deken do its thing
and create this directory. It'll avoid so much unnecessary pain.

Long story short, I'm pretty much with Hans in this regard. Let's Deken
automatically download to a sensible directory.

Just to chime in about unzipping-in-Windows aspect, from what I can
tell that would smoothen the Deken experience for Windows users _a
lot_.

Thanks to all the Deken contributors.

Roman

> > 
> > 
> > * add "Advanced Mode" or "Expert Mode" that shows the current user
> > experience
> > 
> > * remember which mode the user has selected across pd starts (e.g.
> > make
> > a pref)
> yes, many more things should be user-settable, not just two basic
> modes.
> e.g.
> directory-selection:
>  - [ ] ask every time
>  - [x] ask once per Pd process
>  - [ ] choose automatically from existing search-paths
>  - [ ] choose automatically, possibly creating default locations
> 
> as for search results, i was thinking about switching to a tree-view,
> where only the most recent version of a found library would be shown
> by
> default; but opening the (sub)tree, you would see all the older
> versions.
> the wrong-arch results could be grouped together into an
> "incompatible"
> subtree that is closed by default.
> 
> in any case: deken development is somewhat independent of puredata
> itself and is occasionally merged into Pd proper.
> it has it's own bug/feature tracker at [1] and we are happily
> accepting
> merge requests and contributors.
> 
> 
> fgmasdr
> IOhannes
> 
> 
> 
> [1] https://github.com/pure-data/deken
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis
> tinfo/pd-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160609/d79b1832/attachment-0001.sig>