Merge pull request #11 from suelynnmah/main

Updates to psychopy origin

_posts/2023-07-30-psychopy_origins.md

@@ -2,7 +2,7 @@
 layout: single
 title:  "The origins of PsychoPy"
 date:   2024-04-23 10:25:41 +0100
-category: "PsychoPy"
+category: "General Blog"
 tags: psychopy, history
 author: Jon
 ---
@@ -25,21 +25,25 @@ In 2003, Jon moved to Nottingham University as a Lecturer (Asst Prof, in America
 
 In the early years PsychoPy had a few users, a web page, a Google Group, but Jon didn't really provide much in the way of formal support. PsychoPy was for his lab and he made it available, but if it didn't work for you on your system that was... well, just unfortunate! Actually, that's not quite true. Jon discovered that the power of Python meant that he could add things with relatively little effort and so he often spent his evenings and weekends adding features that users requested. He added more stimuli, and the Coder interface, and built the dependencies into an app so it could be installed more easily. That set of features led to the first manuscript about PsychoPy in 2007 (Peirce, 2007).
 
+![Screenshot of version 1.6 Coder Interface](/assets/images/coder.png){: .img-super-right}
+
 ## 2008-9 Adding the Builder interface
 
 Jon was teaching psychology undergraduates to use E-Prime in their practical classes at Nottingham. That wasn't suitable for psychophysics stimuli (it couldn't create the sort of stimuli that vision scientists need) but it was the only software at the time that had a simple enough graphical user interface for undergraduates (and other non-programmers) to create their own studies. Some discussions with André Gouws at the University of York, encouraged Jon to think about what an ideal graphical interface would look like for PsychoPy and to work out the mechanics of what that might do. This was the beginning of creating the Builder interface. It was a lot of work, mostly in evenings and weekends, but by 2009 this was available with a range of simple stimuli and flow controls, as well as the option to add code snippets. It meant that people could use PsychoPy who didn't have any programming experience and it quickly gained traction as a teaching tool. The inner workings of the Builder interface have changed very little since that first iteration, although the stimuli and user interface have improved enormously.
 
+![Screenshot of version 1.6 Builder Interface](/assets/images/builder.png){: .img-super-left}
+
 ## Increasing uptake, increasing features, increasing precision
 
 With a graphical interface the userbase gradually grew. Increasing numbers of departments started using PsychoPy instead of E-Prime (which is expensive and less flexible in the stimuli it can present). This also marked a slight change in direction for PsychoPy because while Jon's own research was in visual neuroscience, the increasing userbase was more in cognitive psychology and linguistics, areas that particularly valued the graphical user interface.
 
-As the user numbers grew Jon, and additional contributors like Sol Simpson, Jeremy Gray and Richard Höchenberger, were working fairly continuously adding further features, like eyetracker support and asynchronous hardware polling, more stimulus types and response options, and generally making the Bbuilder more capable of running studies that were as precise as hand-written code. Indeed, this got to the point that Jon himself started creating his own experiments in the Builder interface rather than by hand (not something he had expected to be doing!).
+As the user numbers grew Jon, and additional contributors like [Sol Simpson](https://github.com/isolver), [Jeremy Gray](https://github.com/jeremygray) and [Richard Höchenberger](https://github.com/hoechenberger), were working fairly continuously adding further features, like eyetracker support and asynchronous hardware polling, more stimulus types and response options, and generally making the Builder more capable of running studies that were as precise as hand-written code. Indeed, this got to the point that Jon himself started creating his own experiments in the Builder interface rather than by hand (not something he had expected to be doing!).
 
 As PsychoPy grew, however, it became hard to keep up with the support needs on a part-time basis while Jon and the contributors had a range of other commitments. There were increasingly frustrating situations where we would know that a bug existed but couldn't spend the time fixing it because of other commitments (like marking undergraduate exams).
 
 ## Grant funding
 
-Ultimately, what rescued the situation was a grant from the Wellcome Trust to port PsychoPy to an online platform (PsychoJS and Pavlovia), followed by a grant from the Chan Zuckerberg Initiative. These grants made it possible for a small team to work full-time on improving the software, documentation and training in the PsychoPy ecosystem. 
+Ultimately, what rescued the situation was a grant from the [Wellcome Trust](https://wellcome.org/) to port PsychoPy to an online platform (PsychoJS and Pavlovia), followed by a grant from the [Chan Zuckerberg Initiative](https://chanzuckerberg.com/). These grants made it possible for a small team to work full-time on improving the software, documentation and training in the PsychoPy ecosystem. 
 
 PsychoPy now has [too many users](https://usage.psychopy.org) for us to contemplate going back to a volunteer-based part-time development model. We absolutely depend on the revenue that comes from [Pavlovia site licenses](https://store.pavlovia.org) and from [consultancy work for users](https://psychopy.org/consultancy.html) in order to provide full-time staff dedicated to the project. That is now possible, thankfully, managed by our social enterprise company, [Open Science Tools Ltd](https://www.opensciencetools.org).