GRCon13 Working Groups: Developing the community and improving user experience¶
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.
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
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
- Too difficult to navigate
- Clicking the logo should go to first wiki page
- Intro page too long
- Too much text
- Could be compressed
- Pages of interest could be a separate box
- Unclear what Sphinx is
- Too many build guides
- Navbar: Mostly useless
- IV can be rolled into II
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.
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.
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.
- Use existing examples/tutorials or make new ones?
- Tutorials for beginners, larger examples later
- Don't tell new user to make their own blocks immediately?
- Assume people have successfully installed GNURadio
- Web page with step1, step2, step3 - not videos
- Web page with annotated screenshot
- Module writing (with modtool) should include examples dir (already does?)
- Add dropdown examples menu to GRC
- Add ability to annotate GRC flowgraphs?
- Many examples don't work or compile or environment isn't setup correctly
- Add QC to examples
- Compile all GRC files, integrate with QA system
- Use grcc to do QA
- All examples must work, change culture such that it's ok to complain about examples not working.
- Add something to GRC that shows missing blocks
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.
A surprisingly easy wish was to have more output on the newsletter than
release notes. We'll try our best!