Forum: GNU Radio GR Community Development / User Experience Working Group

Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (CEL) (Guest)
on 2013-10-08 02:33
(Received via mailing list)
Dear community,

at the last GRCon we discussed the user experience regarding GNU Radio.
A pretty huge group of people came together for a very productive
discussion on how the user experience can be improved.

Our method of choice was to go through the "life cycle" of a GNU Radio
developer, starting at the first time they enter gnuradio.org, through
installation issues and the first time they start using GNU Radio.

We clearly did not have enough time, which is why I would like to invite
the mailing list to continue the discussion in this thread.

But first, let me recap the results from the GRCon working group.
I will give an overview here; for the details, head over to the new wiki
page at
http://gnuradio.org/redmine/projects/gnuradio/wiki...


Web Site
========
Clearly, the web site is extremely important. We need to make sure we
make a good first impression, but then also provide a useful page for
everyone.
Even within our group, we had nearly as many opinions as there were
people. A lot of us agreed the start page has too much content, but as
to what is relevant and what can go to sub-pages, there was no
consensus.

Installation
============
In the future, we want to steer novice users clear from source installs,
and recommend using binary installs where sensible. As soon as 3.7
releases hit the major distros, this will be very easy for most users.
Since for a long time, source installs were really the only viable
option (which gave cause for tools such as build_gnuradio), people have
been getting used to this even though for many cases, source installs
are really not a requirement. Of course, at some stage, they are
necessary, but we want to make sure people only do source installs when
they actually hit this stage.

We definitely need to harden pybombs and get the word out to use that.
However, pybombs needs to be installed through a git checkout, which is
not much more difficult than doing a GR source install. We're not quite
sure how to fix this.

Something we never considered is that people might actually be after one
of the many great OOT-modules (e.g. gr-ais), and simply consider
GNU Radio a dependency. This should be reflected in the install page.

Examples
========
As with most projects, examples are one of the most important elements
when learning GNU Radio. Unfortunately, we sometimes don't treat our
examples very well. Sometimes, they don't even work, but in any case,
there could be more examples available.

This is something new users can do: Create good examples, and test the
old ones. We currently don't have automated QA mechanisms for our
examples, so we need real humans to have a look at them for us.

There was an idea to integrate the examples into GRC, such that we add a
drop down menu which accesses all the installed examples. GRC has
received a very long wishlist though, so don't expect to see this any
time soon (or perhaps add it yourself :).

Beginners who are trying to learn GNU Radio through examples should not
be shy to complain about non-working examples, but rather treat them
like any other bug. This is actually a very nice way to become a
contributor, by filing tickets against broken examples, fixing them or
adding new ones.

Tutorials
=========
Of course, tutorials are also a major component when learning a tool
such as GNU Radio. It was agreed that there are not enough entry-level
tutorials, which also should be accompanied with GRC files. Luckily, we
found some volunteers to work on this.


GNU Radio Companion
===================
An entire sub-working group was created to discuss development on GRC.
There are a lot of expectations towards GRC; fortunately, there are also
a lot of volunteers to help improve it.
A separate wiki page was created to coordinate dev on the companion:
http://gnuradio.org/redmine/projects/gnuradio/wiki...


News
====
A surprisingly easy wish was to have more output on the newsletter than
release notes. We'll try our best!





OK, those were the topics discussed at GRCon13. As I said, feel free to
comment or discuss!

Martin
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstra├če 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-W├╝rttemberg and
National Laboratory of the Helmholtz Association
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-10-09 15:34
(Received via mailing list)
On Mon, Oct 7, 2013 at 8:31 PM, Martin Braun (CEL)
<martin.braun@kit.edu> wrote:
> Dear community,

<snip>

>
> There was an idea to integrate the examples into GRC, such that we add a
> drop down menu which accesses all the installed examples. GRC has
> received a very long wishlist though, so don't expect to see this any
> time soon (or perhaps add it yourself :).
>
> Beginners who are trying to learn GNU Radio through examples should not
> be shy to complain about non-working examples, but rather treat them
> like any other bug. This is actually a very nice way to become a
> contributor, by filing tickets against broken examples, fixing them or
> adding new ones.


All of Martin's comments and suggestions are really good here. I just
wanted to take a second to comment on this problem.

As Martin said, there's no QA code for the examples. One of the main
problems is that many of the examples rely on a hardware interface. I
tried to write a shell script that would exercise all of the examples
it could, but that left out a large number because of the different
hardware requirements.

One thing that might help us is if we had a repository of example
signals that are designed for use with these examples. If you are
working on or creating an example that is supposed to process some
specific signal, like an FM demod for simplicity's sake, make a nice
capture of an FM signal that works with the example and can be played
back. We might be able to throw a switch into the example to select
between a radio source and a file source. That way, we can actually
automatically test that each example works (or at least runs) without
needing hardware.

We wouldn't put the signal captures into the source code, but we can
find room for them somewhere. We already have some signal examples
available through gnuradio.org, so we'd have to download (i.e., wget)
them to run, but that, too, can be easily automated.

Tom
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.