At a recent meeting, we honed the philosophy behind what we report.
Here’s what we decided: Edupack will never clutter admin dashboards with useless reports.
In other words, we’ll only display reports with data that our features impact.
For example, we’ll report usage statistics so admins can tune archive rules to prevent dormant sites. We’ll also report on accessibility errors so admins can automatically nudge problem site owners.
Additional reports may include the number of archived sites over time, the ratio of sites supporting WordPress’ block editor, and the amount of times each block is used.
Keeping to philosophies like these make every aspect of Edupack more useful to Higher Ed Pros we serve.
I’m in charge of Edupack’s outreach. I’m also trying to keep our Slack channels focused by publishing the goals behind our communication and work. This post establishes the motivation behind the #outreach group on Slack.
The Author
From user onboarding to content sunsetting, Edupack aims to simplify Higher Ed web publishing. To reach our bold vision, Edupack is launching an outreach initiative in three phases (enumerated with domain names 😉):
1. Find Good Ideas & Dream Big (joinedupack.com)
Our first phase of outreach needs to promote brainstorming.
Imagine.. Higher Ed web publishing simplified into a single framework of standards and tech..
We’ll search HighEdWeb and WPCampus for good ideas to bring into Edupack.
We are at the start of a big project. The potential is endless, and we should promote big ideas while we can.
2. Deliver Features (edupack.dev)
Once we have all the ideas we can handle, we’ll focus on delivering features. Our features must live up to the dreams of Higher Ed Pros. @nathansmonk and his team are working hard to turn dreams into a reality.
Our aim is to have Higher Ed pros using our plugin as quickly as possible. We want our development to be guided by real user stories.
3. Sustain Openness (edupack.cloud)
We plan to sustain our open core through cloud-basses SaaS products. We love the idea of SaaS products because companies are literally paying us to ensure our code is great and our systems are functional.
I hope that the dreamers and early users who contribute to Edupack become our biggest cheerleaders. Our cheerleaders can push Higher Ed institutions to pay for our services.
That’s my plan for Edupack outreach. Curious what you think!
Edupack caters to every Higher Ed stakeholder. From I.T. admins to professors and students, approved campus users can publish content without design or coding expertise. At our February meeting, Matt presented the following onboarding design iterations.
How are we designing the easiest onboarding in Higher Ed? Answer: Iterate, iterate, iterate…
Our First Iteration
Our first iteration was built around a simple form collecting key pieces of information. The user entered their desired domain, keywords, and selected a “type” of site. Once complete, the user moved to add content from a library of pre-defined blocks.
This raised further questions, such as:
How do we make the pattern library scalable? With space in the sidebar limited, a large number of patterns would be difficult to navigate.
How would a user add functionality to the site?
“Site Type” was confusing to a user. Users who had no knowledge of different site types needed to see what each site type meant.
Take Two
To clarify “site types,” we gave visual examples of different site types.
We added the ability for users to start with a blank canvas. This gives experienced users total control over what content they add.
More questions arose:
Is there a better way to add new pages?
How are relationships between pages created?
How do we deal with endlessly expanding site types?
Take Three
Users often know what pages their sites have. Instead of asking users to fit their content into a page, we decided to offer different patterns of content on each page. A page-by-page setup motivated a sitemap step. The sitemap gives non-experienced users a visual understanding of how their website pages are connected:
The visual sitemap inspired us to visualize other aspects that are confusing in a WordPress site setup, namely the features that a user wants to activate.
Instead of asking users who may not have any WordPress experience to choose plugins, our onboarding form asks users what features they want to add:
Different plugins would be activated behind the scenes, depending on what features a user wanted. Thinking of a site’s features vs. plugins means that network admins should receive fewer requests for plugins that do the same thing as other plugins.
Next steps…
Our onboarding system is now being developed. We’ll soon have a working version installed with all our Braintrust users.
Edupack Blog