This week's newsletter embeds a few images. The on-wiki version might
be easier to read or break less:
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
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!
Function in Wikifunctions early 2022
Function in Wikifunctions early 2023
Object in Wikifunctions early 2022
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
- 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
- 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
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
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
What is left?
What are the main pieces of work we hope to do before we launch
- 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, θ,
- 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
which has been cooking since the summer, has finally hit the review, and
which will considerably improve the performance characteristics of the
- 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:
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.
You may have heard from previous newsletters a bit about the Google.org
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
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.
I shared these findings with the team at our offsite in Zurich during
(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
[image: A main page mockup design showing a "function of the day"]
- 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
[image: A screenshot of the helper text for a new function named Add]
- 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
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
[image: A mockup of a "similar functions groups" design idea for
- 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]
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
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!
The next Wikifunctions & Abstract Wikipedia Developers-Volunteers'
Corner will be held on *Monday 9 January, at 18:30 UTC*
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