The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-01-25
----
Thank you, Google.org fellows!
In April, we shared with great happiness that Google.org were supporting
the development of Abstract Wikipedia and Wikifunctions with a generous
fellowship program. Six fellows joined
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/Updat…>
us
in April and May, and three fellows joined
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-07-20> us
in July. Each fellow stayed with the team for half a year. We thanked the
first round
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-10-27> of
fellows in October, and this week we are sad to see the last fellow leave.
It is time to thank them and appreciate their achievements.
*Sandy Woodruff* joined the team as a designer during a crucial period. We
just were on-boarding our new designer, Amin al Hazwani, so both Sandy and
Amin collaborated closely on defining and refining the use cases for
Wikifunctions, how Wikifunctions will be used, and how to educate users
about the ability of our new project. Sandy wrote a goodbye letter
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-01-11>,
describing her work on the project. Thank you Sandy for great contributions
which we are going to use as a reference in the years to come!
When *Dani de Waal* and *Edmund Wright* joined us, our front end was in
major disarray. We just were changing our data model to support Benjamin
arrays
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-01-11>,
and as the changes propagated through the system, many of our workflows
were broken. Dani and Edmund identified the instability of our project as a
major blocker, and started developing comprehensive front end tests, which
were a major factor leading up to the release of our Beta
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-08-09> in
time for Wikimania 2022. Dani and Edmund continued working on the front end
as well as other parts of the system, and were improving numerous elements
and creating whole new components from scratch. They were both speeding up
the velocity of the front end development, and we are very saddened to see
them go.
It was a pleasure to work with Sandy, Dani, and Edmund. Thank you for your
great work, and we hope that our paths will cross again.
Good bye, Mariya!
*Mariya Shilova* joined us more than a year ago
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-16> as
Senior Technical Program Manager, and her work positively transformed the
Abstract Wikipedia and Wikifunctions team. She accompanied us through
months of turbulent changes, with the on-boarding and changing of team
members, and during the time of the Google.org fellowship
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-10-27>.
The whole team is hugely thankful for her support and the improvements in
process she had led. She also was the main organizer of our first (and so
far only) in-person team off-site
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-05-20> in
May 2022. We are happy that Mariya will continue to work with the Wikimedia
Foundation by supporting other teams. Thank you, Mariya, and expect to be
invited to the (virtual) launch party!
Between the Brackets podcast episode with Ariel Gutman
Yaron Koren <https://www.mediawiki.org/wiki/User:Yaron_Koren> interviewed
Google.org fellow Ariel Gutman as part of his podcast “*Between the
Brackets* <https://betweenthebrackets.libsyn.com/>” in Episode 130
<https://betweenthebrackets.libsyn.com/episode-130-ariel-gutman>. Ariel
wrote a goodbye letter
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-12-19> as
his fellowship ended, and was also one of the co-authors of the fellows’
evaluation mentioned in the same update
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-12-19>.
Yaron and Ariel had an interesting discussion about the feasibility of an
abstract language, the goals of Abstract Wikipedia, and the evaluation. The
episode is 91 minutes long, and follows previous episodes on Abstract
Wikipedia and Wikifunctions. Thanks to Yaron Koren for the continuous
coverage!
The episode can be found here:
https://betweenthebrackets.libsyn.com/episode-130-ariel-gutman
Walidr Pimenta <https://meta.wikimedia.org/wiki/User:Waldyrious> took and
published notes about the episode
<https://workflowy.com/s/between-the-brackets/nIP0OWsPGYPL0aH5>, which can
be found here: https://workflowy.com/s/between-the-brackets/nIP0OWsPGYPL0aH5
Development update (as of January 20, 2023)
- This week we *closed Goal 4* (Implementing the Function view) of the
current Phase of work. The last tasks that were identified last week have
been implemented and all changes are live on Wikifunctions Beta. Functions
are now considerably easier to view, edit, and create than they have been
before. The results have also been featured with screenshots in last week’s
newsletter
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-01-19>.
Congratulations to the team!
- The Experience workstream is now working on *Goal 5* (Implementing the
default view), working on the atomic components that will make up the whole
experience (such as strings <https://phabricator.wikimedia.org/T324243>
and references <https://phabricator.wikimedia.org/T324244>). We are
also identifying the components that need updates in preparation of the
work for *Goal 9* (Updating the other components once Goal 5 has landed).
- In *Goal 3* (Meta-data), the major patch
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/%2B/819176/>
that
has been in the work for months has landed. This stores the meta-data about
the test runs of the implementations. Having this data available allows
Wikifunctions users to understand the performance characteristics of the
different implementations. The final step for this Goal is to have the
system use this stored meta-data to make a smarter decision
<https://phabricator.wikimedia.org/T310199> about which implementation
to use, which will also close this Goal.
- This week, we had the first ever *public meeting of the natural
language generation workstream*. The meeting was well attended, with
eight volunteers and three staff members. We had two presentations, one on
Ninai <https://gitlab.com/mahir256/ninai>/Udiron
<https://gitlab.com/mahir256/udiron>, an NLG system developed by a
volunteer for Abstract Wikipedia, the other on Grammatical Framework
<https://www.grammaticalframework.org/> and the work going into it to
fit with the requirements of Abstract Wikipedia. We also had further
discussions.
This week's newsletter embeds a few images. The on-wiki version might
be easier to read or break less:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-01-19
----
State of Wikifunctions January 2023Where are we?
Since this is our 100th Update newsletter, and it's also a good way to
start 2023, we wanted to give a general overview of the status of the
project, and what is left to do before we launch.
Last year, we saw major progress. We launched the Wikifunctions Beta
<https://wikifunctions.beta.wmflabs.org/wiki/Wikifunctions:Main_Page>, and
saw some engagement there - thank you for everyone trying it out! We also
had the participation of the Google.org fellows, which led to some
reshuffling of our work to accommodate the limited availability of specific
skills. It was a busy year!
<https://meta.wikimedia.org/wiki/File:Function_in_Wikifunctions_during_devel…>
<https://meta.wikimedia.org/wiki/File:Function_in_Wikifunctions_during_devel…>
Function in Wikifunctions early 2022
<https://meta.wikimedia.org/wiki/File:Function_in_Wikifunctions_during_devel…>
<https://meta.wikimedia.org/wiki/File:Function_in_Wikifunctions_during_devel…>
Function in Wikifunctions early 2023
<https://meta.wikimedia.org/wiki/File:Object_in_Wikifunctions_during_develop…>
<https://meta.wikimedia.org/wiki/File:Object_in_Wikifunctions_during_develop…>
Object in Wikifunctions early 2022
<https://meta.wikimedia.org/wiki/File:Object_in_Wikifunctions_during_develop…>
<https://meta.wikimedia.org/wiki/File:Object_in_Wikifunctions_during_develop…>
Object in Wikifunctions, currently in development
Wikifunctions already provides a large number of features:
- Users can *call functions*
- Wikifunctions allows running implementations in *Python* and in
*JavaScript*
- Wikifunctions allows *composing* implementations from functions which
ultimately are written in different programming languages
- Wikifunctions allows for *user-defined types* and user-defined
validators for these types
- Contributors can create *instances* of user-defined and pre-built
types and store them on-wiki
- There is an easy-to-use workflow for *creating functions*
- *Generic types* and *generic functions* are supported by the backend,
allowing for powerful implementations
- Functions can have *several implementations*, and the backend selects
an implementation to run for a given function call
- *Test cases* are run against the given implementations
- The community can *approve and deactivate* individual implementations
and test cases, providing a mechanism for the community to work out what
each function exactly means
- The whole frontend is fully *multi-lingual*, and supports showing and
editing labels in hundreds of languages
- The site works both on *desktop and mobile*. We're excited to provide
an environment where mobile users can benefit from and also create
functions.
- Various *metadata* are collected when a function runs, and made
available in the UI
Just two weeks ago, my eight year old daughter was asking me what I was
working on, and I gave her a quick tour of Wikifunctions. I showed her
the reverse
function <https://wikifunctions.beta.wmflabs.org/wiki/Z10268> on
Wikifunctions, and she thoroughly enjoyed coming up with seemingly
meaningless strings to enter into Wikifunctions, run the function, and make
the system display bad words to us.
The last few weeks we have been focusing on rescheduling and reprioritizing
features in order to quickly move toward launch.
We are currently in the middle of designing and implementing our user
experience. You can see the changes that have landed, and the changes we
are working on in the two pairs of screenshots below.
For now, you can get a preview of the new object viewer
<https://wikifunctions.beta.wmflabs.org/w/index.php?title=Z10426&view=defaul…>
and
contrast it with the current object viewer
<https://wikifunctions.beta.wmflabs.org/w/index.php?title=Z10426> on the
Beta. The interactive features on complex objects are especially
interesting to play around with and compare. This view is in heavy
development right now.
We have also landed a major patch for persistent caching of test results,
which will help with some major performance issues that many Beta visitors
may have noticed. Moreover, it will soon enable another major step: based
on the metadata of the test results, the backend will start selecting
better performing implementations. Whereas currently it is selecting an
implementation randomly, in the near future it will be considerably smarter
than that.
What is left?
What are the main pieces of work we hope to do before we launch
Wikifunctions?
- ensure that function evaluation always runs *correctly*; there are a
few stubborn edge cases left to be addressed (current phase, θ, Goal 2)
- complete the design and implementation of the *user experience*, so
that readers and contributors have a pleasant experience using
Wikifunctions (current phase, θ, Goals 5, 9 and 10)
- create and manage *user rights* relevant to Wikifunctions, as there
are a few new rights that the current wikis don’t have (current phase, θ,
Goal 6)
- display *edit history / diffs*, so it becomes possible to understand
changes in the wiki (current phase, θ, Goal 6)
- fixing a few issues with *error reporting* (next phase, ι)
- provide a *language switcher* for the website, so that users can use
and read Wikifunctions in their own language (next phase, ι)
- collect *metrics* that will help us to understand how Wikifunctions
develops, and to recognize opportunities and bottlenecks in the system
(next phase, ι)
- get *search* working, to help folks find their way around (next phase,
ι)
- enable users to write *documentation for their own functions*, to
explain their functions and foster their use (next phase, ι)
There is still plenty of work to do. You can follow the progress either on
the Beta, where we run the newest development version, or through these
updates, where we will continue to report on our progress.
Looking forward to 2023!
Development update (as of January 13, 2023)
- Major progress on *Goal 4* (Implementing the Function view). In a
closing event, we closed two of the three Critical User Journeys (here
<https://phabricator.wikimedia.org/T318930> and here
<https://phabricator.wikimedia.org/T318936>) associated with this Goal,
and identified the remaining tasks for this Goal. Since then, all but one
could be closed and the last one
<https://phabricator.wikimedia.org/T326656> is in review. We’re very
likely to close this last Critical User Journey
<https://phabricator.wikimedia.org/T318933> on this Goal next week,
including Goal 4 itself too.
- The Experience workstream has appropriately shifted to *Goal 5* mostly
(Implementing the default object viewer). This week we saw the design
for lists <https://phabricator.wikimedia.org/T310827> being locked in,
and the first parts land.
- In *Goal 3* (Meta-data) we only have three tasks left! A major patch
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/%2B/819176/>,
which has been cooking since the summer, has finally hit the review, and
which will considerably improve the performance characteristics of the
system.
- We had the *first volunteer’s corner* of the year. We used Jitsi this
time (but couldn’t use the Foundation instance), and we had seven
volunteers attending. The session was lively and had numerous questions,
and we hope to recruit a new volunteer developer to our wider ecosystem.
This week's newsletter embeds quite a few images. The on-wiki version might
be easier to read or break less:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-01-11
----
Sandy's goodbye letter: On design
Hi Everyone! I am today’s guest newsletter-writer, Sandy.
For the past 6 months, I’ve co-owned UX Design and Research (alongside Amin
Al Hazwani) for Abstract Wikipedia and would love to share my thoughts and
experiences with you.
Background
You may have heard from previous newsletters a bit about the Google.org
fellowship
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-04-12>.
The Fellowship lets Googlers complete up to six months of full-time pro
bono work to accelerate the social impact of Google.org’s top partners, one
of which is Wikipedia.
It has been a great experience to be able to partner with Wikifunctions,
knowing how much this incredible team is contributing to a world in which
every single human being can freely share in the sum of all knowledge.
So, what is it like to be a UX Researcher/Designer at Wikifunctions? Day to
day includes high level things, like conducting user research to assess the
needs and goals of users, crafting user journeys, helping set a long-term
vision for the product from a user-centric lens, all the way down to
designing development-ready design assets (mockups, prototypes) and
prioritizing design tasks, and facilitating implementation.
Starting with Research
Early in the fellowship, I set out to expand on the team’s work on the
target audience for launch, and their mental models.
I conducted User Research with Non-Developers
<https://docs.google.com/presentation/d/1frcJmw9GBBNUc54wV05Gxm4uboN_PWIZ_U8…>
—
people from various industries who may write code but don't identify as
engineers. A lot of my work has been centered around this user group as
ultimately, the hope for Wikifunctions (which can be highly technically
complex) is to be more widely usable and accessible.
High level findings from the study:
The participants interviewed shared a tendency to use libraries of existing
code, where the work of creating functions has already been done by someone
else. They may tweak or make edits, and it can be frustrating to find
exactly what they need. We wondered, if creating functions was easier than
writing code, would that remove the barrier or would they still hesitate to
create their own functions?
We also found that It was only after seeing several examples of what
Wikifunctions can do, that participants understood and were able to apply
ideas for their own field of expertise.
Design Sprinting
I shared these findings with the team at our offsite in Zurich during
a day-long
Design Sprint
<https://docs.google.com/presentation/d/1Blg8gu1oplwNDEq-gZNwce5zWiFtCzrsFUP…>,
(which was based off of a shortened version of the Google Ventures design
sprint format <http://www.gv.com/sprint/>) - it was productive and truly-
so much fun- to engage with engineers and product managers and all types of
team members in sketching and ideating together.
These study and sprint findings informed several design changes and
proposals for Wikifunctions, which aligned with a lot of the hopes the team
had already expressed for improving ease of use.
Here are a few examples of the new features and proposals:
New users and Understanding Functions
*User Goal: As someone who is new to Wikifunctions, I need a way to
understand what functions are, how to write them and how to use them, so
that I can be an engaged member of the Wikifunctions community.*
*Ways to address that goal:*
- Giving users a chance to engage quickly with a function on the
homepage to get a better sense of how it works at a glance, for example,
this "function of the day" (Rather than create an entirely different
experience for new users, we found it preferable to integrate text and
features that could be beneficial and interesting to both new and
well-versed users.)
[image: A main page mockup design showing a "function of the day"]
<https://meta.wikimedia.org/wiki/File:WikiLambda_main_page_mockup_Function_o…>
- Helper text, that provides assistance to those who are looking for it,
to explain what is required for each field when creating a function
[image: A screenshot of the helper text for creating a new function at
Wikifunctions]
<https://meta.wikimedia.org/wiki/File:WikiLambda_helper_text_Create_function…>
[image: A screenshot of the helper text for a new function named Add]
<https://meta.wikimedia.org/wiki/File:WikiLambda_helper_text_Add_function.png>
- Creating a space for lengthier explanations of complex concepts -
like, “What is a type? And how can I determine which type to choose- when
defining a function?”
[image: A screenshot of the helper text for lengthier explanations of
complex concepts]
<https://meta.wikimedia.org/wiki/File:WikiLambda_helper_text_for_complex_con…>
Discovering relevant functions
*User Goal: I need a way to discover relevant functions, so that I can find
an answer to my query and know that I am not duplicating work.*
*Ways to address that goal:*
- Highlighting several categories on the homepage that we know are of
interest to certain groups, for example, "functions for editing wikipedia"
and "functions for natural language" and "functions to get started with"...
These lists (and new ones!) would be editable and contributed to by the
community.
[image: A mockup of a "similar functions groups" design idea for
Wikifunctions]
<https://meta.wikimedia.org/wiki/File:Wikifunctions_design_idea_grouping_fun…>
- On the function page, showing related functions- as a way of easily
jumping from one relevant function to another, and to get a sense of what
functions are out there in that particular space so as not to duplicate a
function that already exists.
[image: A mockup of a "related functions" design idea for Wikifunctions]
<https://meta.wikimedia.org/wiki/File:Wikifunctions_design_idea_related_func…>
Implementation
Another huge part of my role and responsibilities has been working closely
with the development team to implement all these features and ideas.
Together, designers and engineers go through with a fine toothed comb and
refine specific interactions. The one thing you can count on is:
discovering use cases or roadblocks you didn’t anticipate! We also depend
on close collaboration with the design systems team
<https://www.mediawiki.org/wiki/Design_Systems_Team> — whose responsibility
it is to ensure UI consistency across Wikimedia projects.
[image: A screenshot of various test cases when using the WikiLambda
interface]
<https://meta.wikimedia.org/wiki/File:WikiLambda_design_nuances_using_Codex.…>
Finally, a meta-goal I’d like to speak to is:
Sharing design work with the public
It’s important for not just Wikifunctions but for the organization as a
whole to keep the public updated on how we are thinking about this project
from a design perspective, and invite the community (you all!) into the
conversation to provide clarity on what a product should be.
*Hopefully this newsletter is another step towards that goal!*
You can also take a look at our page here
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Design> and add your
name if you would like to contribute to future user research.
Thank you for reading!
------------------------------
Public NLG workstream meeting on Tuesday
Reminder: next week on Tuesday, we will host the first public meeting of
the natural language generation workstream. The workstream includes the
volunteers and staff that have been working together in the last few months
on exploring the natural language generation work that will be necessary
for Abstract Wikipedia. Everyone is invited to join. The meeting will be on
Tuesday, January 17, 2023, 16:30-17:30 UTC and you can join on JITSI on the
following link: https://meet.jit.si/AWVolunteersCorner
This week’s volunteer corner on Monday, January 9, had seven volunteers
joining. We had a lively discussion about the project, and we remain amazed
by the volunteer developers and their contributions to our codebase. Thanks
everyone for attending!
Hello all!
The next Wikifunctions & Abstract Wikipedia Developers-Volunteers'
Corner will be held on *Monday 9 January, at 18:30 UTC*
(https://zonestamp.toolforge.org/1673289016)
Link to the meeting: https://meet.wmcloud.org/AWVolunteersCorner (we
are experimenting with the Wikimedia-based Jitsi platform, so
apologies in advance for any problem that might arise)
Of course, everyone is invited to join and ask their own questions.
The meeting is for everyone, from more experienced users to complete
newbies. There is no need to register, just click on the link and
you'll be immediately in the meeting.
See you there!
--
Luca Martinelli [Sannita] (he/him)
Community Relations Specialist
