7:12 a.m.
At the recent gretl conference in Athens (thanks, Ioannis!) we
discussed potential improvements to some aspects of the gretl GUI.
To avoid overburdening this post I'll confine myself to one point
here, namely access to information about function packages. (I'll get
to some of the other points later.)
As a reminder, in the current release we have a toolbar button labeled
"fx" which supports browsing packages on the local machine or server,
and we have several relevant entries under the Tools menu (access to
the browsers plus other stuff).
One suggestion that got some traction was a "Package" (or "Packages")
top-level menu in the main window (between "Model" and "Help"). The
idea was to move all the package-related menu items from under Tools
to this new menu, to increase the visibility of packages.
I've implemented that in current git and snapshots, but personally I'm
not all that happy with the result. I don't insist on "having my own
way" on this, but I'd like to explain my view and hear what people
think.
First, the "Package" menu has 3 blocks of material: (1) items that
point to the package browsers; (2) items to do with creating/editing a
function package; and (3), if you've edited any packages lately, a
listing of recently opened package files. Note that only block (1),
with its two items, is relevant for "general" users who aren't in the
business of editing packages. All the other stuff, IMO, really belongs
under the File menu because, well, it's all about files. And it looks
wrong to me that it's separated so widely from "File".
So I would favour putting at least the package-editing items (that is,
blocks (2) and (3)) under a new entry "Function packages" in the File
menu (in the section that currently has "Script files", "Session
files" and "Databases"). Access to the browsers could also go there,
but maybe (also?) under Help (possibly combine with the Addons item?).
The File menu surely gets a lot of traffic, so having packages there
would make them somewhat more visible that under Tools. I suppose
there _could_ still be a "Packages" top-level item, but I'm not sure
about using that space for a menu with just two items (the browsers).
I'd also point out that we discussed other ways of making packages
more visible, which I certainly support: sending a regular (say,
monthly) email to the users list with a round-up of new or updated
packages; making packages more prominent on the gretl website; pushing
out info via Facebook and/or Twitter. If we can get those things going
I'm not sure we need a dedicated Package menu.
Allin
10:16 a.m.
On Fri, 9 Jun 2017, Allin Cottrell wrote:
At the recent gretl conference in Athens (thanks, Ioannis!) we
discussed
potential improvements to some aspects of the gretl GUI.
To avoid overburdening this post I'll confine myself to one point here,
namely access to information about function packages. (I'll get to some of
the other points later.)
As a reminder, in the current release we have a toolbar button labeled "fx"
which supports browsing packages on the local machine or server, and we have
several relevant entries under the Tools menu (access to the browsers plus
other stuff).
One suggestion that got some traction was a "Package" (or "Packages")
top-level menu in the main window (between "Model" and "Help"). The
idea was
to move all the package-related menu items from under Tools to this new menu,
to increase the visibility of packages.
I've implemented that in current git and snapshots, but personally I'm not
all that happy with the result. I don't insist on "having my own way" on
this, but I'd like to explain my view and hear what people think.
First, the "Package" menu has 3 blocks of material: (1) items that point to
the package browsers; (2) items to do with creating/editing a function
package; and (3), if you've edited any packages lately, a listing of recently
opened package files. Note that only block (1), with its two items, is
relevant for "general" users who aren't in the business of editing
packages.
All the other stuff, IMO, really belongs under the File menu because, well,
it's all about files. And it looks wrong to me that it's separated so widely
from "File".
So I would favour putting at least the package-editing items (that is, blocks
(2) and (3)) under a new entry "Function packages" in the File menu (in the
section that currently has "Script files", "Session files" and
"Databases").
Access to the browsers could also go there, but maybe (also?) under Help
(possibly combine with the Addons item?).
The File menu surely gets a lot of traffic, so having packages there would
make them somewhat more visible that under Tools. I suppose there _could_
still be a "Packages" top-level item, but I'm not sure about using that
space
for a menu with just two items (the browsers).
I'd also point out that we discussed other ways of making packages more
visible, which I certainly support: sending a regular (say, monthly) email to
the users list with a round-up of new or updated packages; making packages
more prominent on the gretl website; pushing out info via Facebook and/or
Twitter. If we can get those things going I'm not sure we need a dedicated
Package menu.
I was one of those who proposed a "Packages" entry in the top-level menu.
My point of view, as Allin knows, is that in the mind of a typical user
installing and (most importantly) using packages has nothing to do with
loading and saving stuff. A package is just like an extra goodie that is
already "out there" somewhere, so to speak, and your decision is just
whether to enable it or not. But in order to take such a step, first you
must be aware of its existence in the first place.
Imagine the situation of someone, not very familiar with gretl, in need of
some functionality that's contained in a function package; say, for the
sake of the example, fixed-effects Poisson regression. I would guess the
steps the user would take are:
1 - Look under Model > Limited Dependent Variable > Count data. Ok,
Poisson is there, but only the pooled variant
2 - Try Model > Panel. Hm, no luck.
3 - Assuming the user hasn't concluded by now that there's no way of doing
this in gretl, try the Help menu. Maybe even open the User's Guide and the
Command Reference, and maybe use the "Find" function of her pdf reader.
Nope, fixed-effects Poisson isn't there.
4 - Ok, let's google for it. If you google for "fixed effects poisson
regression gretl", the 5th entry[*] gives you "gretl function packages";
if you click, you'll get
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS
where you are told that in order to get what you want (assuming you spot
it down the list) you have to go to the Tools menu etc.
The point I'm trying to make is that only a minority of users are likely
to get to step 4, and even if they eventually get there maybe, at that
point, couldn't be bothered to go to some menu they've very seldom (if
ever) visited, and perform actions they may not be sure about (could this
be a virus? will I break my installation of gretl? what are all the funny
things that appear in my browser if I click on the package I need?)
On the other hand, if you get some top-level menu entry that hints at the
fact that gretl can be extended and customised, a causal user may be not
only more willing to do so, but will also probably get into the mindset of
EXPECTING some functionality to be contained in some extra item (think of
Excel users and their love for add-ons). Actually, I can even see this to
increase the chances of people wanting to _provide_ their own packages.
In Athens, I thought that a "Packages" top-level entry would do just that,
but I'm very open to considering alternative ways to achieve the same
effect. For example, we could have a top-level menu called "Customize", or
something like that, with the window we now have under Preferences>Tools,
plus the items related to package download and installation. Other items,
relevant to package writers, may be buried deep somewhere else. I have no
objection on that.
[*] I remember that some time ago I read somewhere that a large share of
google users only look at the first 2-3 matches, but here I'll assume our
hypotheical user goes beyond that point.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:33 p.m.
Am 09.06.2017 um 16:16 schrieb Riccardo (Jack) Lucchetti:
On Fri, 9 Jun 2017, Allin Cottrell wrote:
...
> One suggestion that got some traction was a "Package"
(or "Packages")
> top-level menu in the main window (between "Model" and "Help").
The
> idea was to move all the package-related menu items from under Tools
> to this new menu, to increase the visibility of packages.
>
> I've implemented that in current git and snapshots, but personally I'm
> not all that happy with the result.
[And in the meantime it was changed with the result visible in the
current snapshot, I believe.]
Without going into all the details, I think the current (June 17th
snapshot) arrangement is quite good -- changes that are not too
disruptive but go in the right direction IMO.
3 - Assuming the user hasn't concluded by now that there's no
way of
doing this in gretl, try the Help menu. Maybe even open the User's Guide
and the Command Reference, and maybe use the "Find" function of her pdf
reader. Nope, fixed-effects Poisson isn't there.
Good point, and actually -- why not? I mean, why not include a list of
function packages as a further appendix in the user guide? (Basically
the same list which is at:
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS.)
Of course that list as copied into the guide will become slowly outdated
as packages are added and updated quicker than new gretl versions are
released, but that isn't a big problem IMO. The appendix in the user
guide could start with a reminder "current as of the date of release;
for the up-to-date list choose File/Function packages/On server" or
something.
cheers,
sven
2:13 a.m.
On Sun, 18 Jun 2017, Sven Schreiber wrote:
> 3 - Assuming the user hasn't concluded by now that
there's no way of doing
> this in gretl, try the Help menu. Maybe even open the User's Guide and the
> Command Reference, and maybe use the "Find" function of her pdf reader.
> Nope, fixed-effects Poisson isn't there.
Good point, and actually -- why not? I mean, why not include a list of
function packages as a further appendix in the user guide? (Basically the
same list which is at:
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS.)
Of course that list as copied into the guide will become slowly outdated as
packages are added and updated quicker than new gretl versions are released,
but that isn't a big problem IMO. The appendix in the user guide could start
with a reminder "current as of the date of release; for the up-to-date list
choose File/Function packages/On server" or something.
Allin just added a "packages" entry to the Help menu, which IMO makes the
point sort of moot.
One thing that could be quite useful in the same vein could be some sort
of search facility: suppose we had, under the help menu, a "Search" entry,
by clicking which you get a text box. You enter a term (say "panel
Poisson", to continue with the example), and you have an automatic
text search through the pdf doc, the info files of the packages on the
server, and possibly google (suitably filtered) as a last resort. That
should do it, I think. I believe Stata's got something like that.
Implementing this would not be trivial, but I guess many users would like
it.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
3:37 a.m.
Am 19.06.2017 um 08:13 schrieb Riccardo (Jack) Lucchetti:
On Sun, 18 Jun 2017, Sven Schreiber wrote:
>> 3 - Assuming the user hasn't concluded by now that there's no way of
>> doing this in gretl, try the Help menu. Maybe even open the User's
>> Guide and the Command Reference, and maybe use the "Find" function of
>> her pdf reader. Nope, fixed-effects Poisson isn't there.
>
> Good point, and actually -- why not? I mean, why not include a list of
> function packages as a further appendix in the user guide? (Basically
> the same list which is at:
> http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS.)
Allin just added a "packages" entry to the Help menu, which IMO makes
the point sort of moot.
Hm, at least it should be "extension packages" or something more
self-explanatory. But otherwise, OK, perhaps. Can always add that later
as well.
cheers,
sven
4:38 a.m.
On Mon, 19 Jun 2017, Riccardo (Jack) Lucchetti wrote:
On Sun, 18 Jun 2017, Sven Schreiber wrote:
>> 3 - Assuming the user hasn't concluded by now that there's no way of
doing
>> this in gretl, try the Help menu. Maybe even open the User's Guide and the
>> Command Reference, and maybe use the "Find" function of her pdf reader.
>> Nope, fixed-effects Poisson isn't there.
>
> Good point, and actually -- why not? I mean, why not include a list of
> function packages as a further appendix in the user guide? (Basically the
> same list which is at:
> http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS.)
>
> Of course that list as copied into the guide will become slowly outdated as
> packages are added and updated quicker than new gretl versions are
> released, but that isn't a big problem IMO. The appendix in the user guide
> could start with a reminder "current as of the date of release; for the
> up-to-date list choose File/Function packages/On server" or something.
Allin just added a "packages" entry to the Help menu, which IMO makes the
point sort of moot.
I'd encourage people to take a look at the Help text under the
"Packages" menu item and suggest any additions that might seem
helpful.
One thing that could be quite useful in the same vein could be some
sort of
search facility: suppose we had, under the help menu, a "Search" entry, by
clicking which you get a text box. You enter a term (say "panel Poisson", to
continue with the example), and you have an automatic text search through the
pdf doc, the info files of the packages on the server, and possibly google
(suitably filtered) as a last resort. That should do it, I think. I believe
Stata's got something like that.
Implementing this would not be trivial, but I guess many users would like it.
I like that idea. As you say, non-trivial to implement but would be
nice to have.
Allin
2708
days inactive
2718
days old
5 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber