This is great to read! I am also excited about the Question feature, and advocate for a direct link to Asking Questions (and Answering Questions) on front of our website. On a personal note, i would post more notes while events are actually happening if i could email in a photo and a subject line (for the title), and some body text.

Hmm, interesting. Do you feel that's much easier than using the smartphone-friendly posting form?

Did you know you can use "Add to home screen" on most phones to make the posting form into an app-like icon? I understand that it's not "the same" as just emailing in. But do you think it's more of an issue of people not knowing they can do this, or that it's really a fundamentally different interaction, or is this more about your specific smartphone interaction preferences?

If we wrapped just the post function up into an app, we could probably make it an Intent, so that people could "Share to Public Lab.org" from the photos app, for example. But this would only work on Android - Apple doesn't allow it.

Great idea - i have just created an icon that goes directly to publiclab.org/post. I will give that a shot for a while and report back. One thing i will keep an eye on is how often (every time? every day?) i have to log in, because logging in on mobile is not so fun, compared to emailing in which presumably would somehow already be connected to my PL account.

Hmm, I don't find that I have to log in that much; perhaps you should open an issue for that, as it should remember you. But yes, that's an extra step it'd be nice to avoid.

Thanks Jeff. As always, thoughtful with an eye for how to broaden participation and make more inclusive. For me, being busy and spread thin is an issue. The shorter mode could help. Pat

Since our inception, looking at and using Markdown has scared off posters-- and I know this because people have been telling me this for four years, in workshops, and I'm not alone. How many people need to bring this feedback up before its treated seriously as actual feedback from real users who don't post, rather than one "question" among many that push us in "different directions?"

We've mitigated this barrier ( the high floor we ACTUALLY have) somewhat with drop-in image uploading and some style guides, but the intimidation factor of either not feeling able or not feeling able to learn to post "nice looking" research notes of the style that more expert Markdown users post is pretty high.

I would disagree that the issues of using Markdown for longer posts and wiki pages mean that fixing this issue with a WYSIWYG editor pushes us in the direction of longer-form content. I think that is a poor framing of the issue. This is merely the framing captured by Github, because it is the way current users understand the problem. It fails to capture the range of feedback we've actually gotten.

I know I'm going to come off cold and inhuman, but we should not ignore mathematics and known trends.

Most natural works, and human works, exist in some kind of network. As a result of the way networks operate, we tend to see Power Law or Parieto Principle all over; it is often summed as the 80-20 rule. 20% of entities in a network contribute to or are responsible for 80% of something in the network, and 80% of entities likewise represent 20% of the measurement. I think we see exactly that pattern with the number of users who contribute great or small quantities of research notes. Using 80-20 language: 20% of the users contribute 80% of the total research notes, and 80% of the users contribute only 20% of the total research notes. I think this is neither bad nor unexpected. If anything, it demonstrates a healthy network, if not a utopian one ;)

Additionally, I think the post count for four active users is very likely to be well modelled by a Poisson distribution. As told by Wikipedia, such a distribution arises from "a given number of events occurring in a fixed interval of time and/or space if these events occur with a known average rate and independently of the time since the last event".

Clarification of the Poisson process is made by way of example: "For instance, an individual keeping track of the amount of mail they receive each day may notice that they receive an average number of 4 letters per day. If receiving any particular piece of mail doesn't affect the arrival times of future pieces of mail, i.e., if pieces of mail from a wide range of sources arrive independently of one another, then a reasonable assumption is that the number of pieces of mail received per day obeys a Poisson distribution."

So there are two things to ask with that respect: 1) assuming a Poisson distribution of posted research notes, can we decide on average post rate for each user (and is that metric meaningful)? 2) assuming a Poisson distribution is true, why are the note posting times independent from each other? Given the narrative of this research note, one would think notes should be related to each other and thus posting times would be related. Perhaps this is true and the posting distribution is not Poisson. It would be interesting to try to model the post distributions to find out.

Hey Mathew - maybe you misunderstand -- I'm not speaking against a WYSIWYG editor - we've clearly agreed on Github that it's a priority, and my understanding is that we're working to dedicate some staff time towards it in the coming year. A shorter note format could definitely be WYSIWYG.

I agree that WYSIWYG doesn't mean longer, and that we should think of length and ease of interface as separate issues. Given that we've made a WYSIWYG editor project a priority, I'm mostly interested in the question of research note length at this point.

I do think the idea of a "plain text only" version of a post is interesting, though, for high frequency (day-to-day) or first-time posters. What do you think of that concept?

For plain text only, we might want to look into something like what TwitLonger does. http://www.twitlonger.com/

Twitter begins as just text with 140 characters. TwitLonger breaks the 140 character limit and supports line breaks, but that's about it. It's just text and links.

Since Twitter is accessible, tons of people already use it. I wonder if we could make a way to generate a research note for a user if they send a TwitLonger link to @ publiclab on twitter? Then research notes could be written using someone's favorite long tweet supporting app.

I don't misunderstand this note, Jeff. It has two sections: a diagnosis of the problem of research note posting, and a proposed remedy-- working on shorter form content strategies. I'm not addressing the question of whether shorter-form content is a good idea right now, I'm addressing the incompleteness of the diagnosis for not taking seriously the idea that Markdown is a user interface issue effecting content posting:

"The research note posting interface has been carefully crafted to emphasize simplicity and clarity. But it's definitely not designed for longer-form work. Some on the organizers list and on Github have argued persuasively for a richer, more powerful editor that is simultaneously easier to use without knowing Markdown, the simple formatting system we use.Many of the above issues seem to push us in different directions. What I'd like to explore is the possibility of a shorter research note format, perhaps as an alternative in parallel with a longer version."

Am I misreading that? it says: 1) the notes are simple and use a simple formatting system right now 2) it isn't designed for long-form work, and we have a persuasive case that WYSIWYG would help that.

Then there's this statement: "But what about everyone who didn't post? I'd like to focus on that hard-to-measure group who we didn't manage to entice into posting something. Basically -- selection bias: we don't have feedback or input from those who aren't participating."

But we DO have some feedback from some people who aren't posting and they've been complaining about Markdown since we started using it four years ago.

After harping on the usability of Markdown for four years, yes, it is now a Github priority on development. But is is actually one? Is it recognized by our Web Team as a priority, as a problem affecting posting? Or is it begrudgingly accepted as something in-demand? if the Web team isn't writing it into their diagnosis of usability issues, I fear it won't be.

It's absolutely a priority -- so much so, that throughout this note, I've treated it as a given that we're implementing it.

Am I misreading that?

Let me try again on what I mean in that paragraph:

• we spent lots of effort to strip down the research note form and simplify it
• both Markdown and our shorter, smaller form are especially bad at long-form work
• we are implementing a WYSIWYG editor to address the Markdown problem
• I hope that in all these efforts, we keep ensuring that our interfaces are simple and clear
• I think a move towards longer form has value but has to be balanced against the advantages of a shorter form

I'm sorry, I didn't mean to just skip over our nearer-term plans here; I'm just looking ahead to what'll come after that. So when I want us to account for selection bias, I mean with regard to longer vs. shorter notes and other issues we'll be facing after the WYSIWYG project. I hope that addresses your concerns!

Kudos all around for a great site!

1. I love the Notes and feel guilty I'm in the 80th percentile of lurkers--will have to post something.
2. Wiki pages are nice but I can't help but think that rather than being the "information super highway" people intended, they are more like "information parking lots" of the internet. There seem to be about 900 wikis? Some have good content but it's hard to find wikis of value unless it's referenced in a Note.
3. Then what about PLOTS google groups? It's like the legacy Q&A section that I keep forgetting even exists. I think the groups could be reincarnated as a front page Q&A section.
4. And lastly, another need would be for announcements and events. For example, EPA is holding a live webinar on citizen science air monitoring on July 9th but I don't know how to convey stuff like this.

I am also interested in a plain text question posting option. Would be good to be able to include pictures though, with an upload method that people understand from other common social media or email standards.

This was brought up several times during the Barnraising also. There were so many awesome people there with great ideas and lots to say, yet I haven't seen them on the Wiki. So we are losing them somewhere. Maybe it's not in the process of posting Research Notes; maybe it's in the process of actually just getting to them? What I kept hearing was more along the lines of "I went to the site, I got overwhelmed/intimidated, I left the site"... I'm not sure they are even getting to the text editor part of it.

Lurkers, I see you out there! Feel free to chime in!

When the team I worked with at the Berkeley School of Information was working on our thesis project we looked a lot at how to build intrfacws that encourage easy, low effort contributions to bring someone into a community. One thing we built into rhe platform we developed was modularity on projects. Someone could start a project and add content (such as a Mapknitter map, text, other photos/videos) and they would own that project. But anyone else could request access to the project to submit to it. They might kit have much to add, but it would make them feel more connected than just commenting, since it feels more like a real contribution. Our platform was obviously for a different audience/purpose than public lab, but making it easier for people to collaborate and contribute to each other's work is one option.

User-documentation issues have been THE most challenging problem for just about every grassroots organization I've ever worked with. For projects/campaigns where the primary object was textual/software based, github has always emerged as the best option, even when you factor in the learning curve for non-programmers (and I say this as someone who only recently started identifying as a programmer...). The github format somehow always led to frustration when it came to documenting projects with any kind of physical element however. When my hopes for a "github for hardware" finally did materialize with the likes of Upverter etc... I found the learning curve favored those with professional engineering backgrounds even more than Github does with programmers.

In this context, I found the research note format to be by far the best grassroots, user-documentation platform I have yet used! The key to its success IMHO is in its flexibility. Any single entry can variously serve as a narrative blog post, a Github readme, a step by step tutorial, a journal entry or a discussion forum. On the other hand, I could see how the very flexibility that makes it so useful could also make it difficult to evaluate its effectiveness. I have noticed my posts have been getting less comment activity then a year ago when I could always count on a lively discussion following every new post. Part of this might be related to the separate discussion forums but then again I've noticed activity on almost EVERY listserv-style discussion list I've been involved in has been declining too...

I have no idea if the metrics support this or not, but my point is that the research notes have the ability to evolve in ways that a discussion forum doesn't. So sometimes I'll post a note on something that'll collect dust for months on end and suddenly I'll get an email out of the blue from somebody who saw it and wants to collaborate and the project springs back to life...

In order to ensure the format as a whole continues to evolve, I suggest we take advantage of the power of Markdown!

Speaking as a relative newcomer to the programming world, I like to think I can speak with a certain degree of confidence on what can be considered "accessible" and what is an overly technical interface. So folks will have to trust me when I say MARKDOWN IS NOT OVERLY TECHNICAL!!! Especially, when it is presented in the research note editor! However, so long as we're using it, we might as well take full advantage of its flexibility. This could potentially mean much more than editing from a mobile phone. The cross-platform nature of markdown formatting could be used to fully realize the multi-functional potential the research notes have already demonstrated.

In other words, instead of a note functioning "like a blog" why not allow the content to be reformatted AS A REAL BLOG! I've been experimenting with something along these lines with various markdown-based blogging platforms like GHOST. Unfortunately, hosting requirements proved too much of a headache for me to stick with GHOST. Other platforms like Jekyll, offer a unique solution to the hosting problem by hosting the content in a Github repo via the gh-pages feature. The Ruby-based Jekyll code has always been another barrier for me however, but more recently platforms like hubpress.io have combined the best of both Jekyll and GHOST by providing a node.js framework hosted using gh-pages. Since all the posts would be written in markdown anyway, it would be amazing if we could use some of our research notes as blog posts and vice versa. So if I have a project I would like to share, I would only have to write it once, and the same document could transform into a discussion forum post, blog post, readme file in a code repository etc...

@ajawitz I'm not sure if you have seen the (lengthy) discussion on Markdown in various places, but I can link to at least one part of the longer conversation: https://github.com/publiclab/plots2/issues/151

Very likely we'll be putting a user interface that users can use without knowing or caring how the actual markup text looks. Buttons and that, like word processors that most users are already familiar with. In the backend, we will likely continue storing the markup information as Markdown, which would still support exporting markdown for various other uses. The difference is whether the user must use the markdown directly or use pretty buttons and pretty rendering which hides the Markdown.

There might be a "raw" button that lets advanced users edit the markdown directly if they feel comfortable with it.

I think that's a suitable summary of the current discussion.