More Looking at a Domain of One’s Own – cPanel

So I’m still getting settled at the new job. It leads to ebbs and flows in energy. I opted to lay off the “long goodbye” posts for a while as they were making me a bit depressed. It was getting rough to look back at selected highlights made over 7 or 8 years while I struggle to make initial relationships over zoom and email. VCU had plenty of hard times where it felt like what I had to offer had no value. I remember that. It took quite a while to get to know people and show them opportunities that both of us wanted to pursue. I’m also just trying to relax a bit more. I have a tendency to think way too hard initially as I struggle to fit in to the place and make sure I’m not making mistakes.

On what might be a more useful note, I’ve come back around to our Domain of One’s. This particular look will be at cPanel. I’m not sure how much we customized and how much is stock. I know there are options there but I don’t know the full extent of choice. I tend to figure out what I’d like to do in a perfect world and then go about trying to do it so with that, let’s take a look.

cPanel

Applications

Initial cpanel display showing WordPress, Omeka, Grav, and Scalar as the main apps.
We start by showing people WordPress, Omeka, Grav, and Scalar as the things we seem to think are the most useful based on the priority we give them.

We can start thinking about whether this is what we want and how shifting what we present here might change usage, understanding, and perception.

If you scroll down the page, the next place we show applications is the “Web Applications” section.
cPanel view showing ownCloud, MediaWiki, Megento, LimeSurvey, Joomla, Piwigo, and Drupal.
Do we agree that ownCloud, MediaWiki, Megento, LimeSurvey, Joomla, Piwigo, and Drupal are the apps we want here? What’s driving that? Do people even get down this far? It is the 8th of 11 sections. It could very well not matter.

Maybe we need to think about the whole structure of this page and the language the guides its structure. I’m not entirely sure how much we can change but assuming we can completely restructure things, do we think this structure makes the most sense? It’s a mix of what we think people will want to see/change/use and what we want to try to get them to use.

Currently the order and language is as follow.

  1. applications
  2. domains
  3. files
  4. email
  5. databases
  6. security
  7. web applications
  8. software
  9. advanced
  10. preferences

I see some places for confusion. I couldn’t tell you the differences between applications and web applications in this scenario. Is there another name for software that might work?

I also see the chance to really restructure elements to parallel how we want people to think and what we want them to focus on. In a perfect world I’d want to blend options to get understanding in conjunction with options to take action.

All Applications Browser

I wanted to see what we’re telling people implicitly and explicitly when we put them in the cPanel app browser. There are lots of things going on here. I’m thinking about how things are presented in order and what language we use to categorize them.

Pure numbers

We have 163 apps available. They’re in six categories (community, content management, e-commerce, Photos and files, Surveys & statistics, Miscellaneous).

When I look at it like this, I really want to remove a lot of e-commerce apps. They are third in terms of order when we present them and second in terms of total number of apps. That’s a lot of attention especially given we don’t want people using MiddCreate for commercial purposes. Granted you can use these apps for different things but by labeling it this way we are encouraging a particular mindset.

I also took the sub-categorization straight from cPanel. There’s more variance here in a way that’s probably good but we still have e-commerce coming in second. I did re-label some of the custom WordPress setups (Alan’s calling cards and Splots) as WordPress rather than CMS because I felt it was more accurate.

Bigger Picture Alignments

All these things matter but are dependent on our goals and the language behind them. DoOO initiatives are often focused on digital literacy/fluency and digital identity. There’s a huge amount of different ways to think about those things. However, when you come to this essential piece of the experience, is it reflecting how your group is defining the idea? Is the language parallel? Does cPanel end up helping, hurting, or doing nothing?

Comments on this post

  1. Alan Levine said on April 10, 2021 at 9:16 pm

    I shudder to send people to cpanel, sometimes myself. After years I only truly know what maybe 25% of the things are.

    But a significant difference between cpanel bewilderance and the one people get in say WordPress or even those LMS things is that you do not venture to cpanel on a regular basis, it’s not where you go to do your work. Maybe it’s a difference between using your car everyday to get to work and maybe having to lift the hood every three months to check the oil (not that anyone really does that).

    There’s not much memory making learning of cpanel that comes from repeated tasks, maybe more important to have good cheat sheets. At a minimum, knowing how to reorder the main panels. It would be nice to create something like OS X views of it

    • Tom Woodward said on April 12, 2021 at 8:52 am

      I think that’s what I’m trying to get at . . . how can we shape the cPanel experience to reflect our intent?

      Are we trying to teach people about cPanel? If so, what elements? How does it reflect larger goals?

      If we aren’t trying to teach cPanel how do we set up our process to get around it or through it as efficiently as possible?

      To play with the car metaphor a bit more, if we’re trying to teach people to check their oil . . . what if we could hide all the other engine parts? That could be bad if we’re saying that in a future car (down the road) those elements wouldn’t be hidden. You’d be confused. It could be fine if all we’re saying is that you need to get the concept behind checking your oil and that it’s likely how you do it will vary as you move to different cars.

      This is kind of where I’ve struggled with the DoOO idea in the past. What depth of technical experience do people expect from this experience vs what is just about giving choice regardless of technical knowledge acquisition? There’s no right or wrong there but it is a thing I’d like better articulated in how people talk about these initiatives. The technical knowledge route requires some goals and some patterns that intentionally expose complexity while the choice route would likely try to avoid complexity in favor of ease/direct access.

      • CogDog said on April 12, 2021 at 4:12 pm

        Can’t say I can easily answer those good questions. Myself I’d prefer to generate some curiosity, but the interface is so baffling and lacks compelling information or examples of what everything does. It rather appeals to people who know how to manually adjust their carburetors.

        But can the interface engender curiosity? Maybe it can nudge.

        So your web site’s check engine light comes on, what do you do? After that happened to me while driving across mountains in Colorado, I was forced to contact tech support (aka take it to a garage). The light gives you no information. It could just be a loose or missing gas cap.

        For more metaphoric driving I got a gizmo I could plug into the port under the dash and display the actual code, then I could look it up and be informed. But I went beyond, and got a nifty bluetooth powered adapter that replaces the plastic cap on the interface. It sends data to an app on my phone. I can get real time engine data, but also the exact code for a problem, and even reset it. I’m still no engine mechanic, but I can have more information than a warning light.

        • Tom Woodward said on April 13, 2021 at 6:59 am

          Curiosity is always a good goal. I am looking at just how far I can bend cPanel. It looks like I can throw javascript in there so that opens up a can of options. Maybe more in-situ guidance with Shepherdjs or something like that.

          I wonder if I can’t tier it better and expose complexity as you move down or maybe do some more contextual information that explains what happens when you click on that button. That gets closer to your gizmo scenario.

          To beat this metaphor into the ground then stomp on it a bit, I think we’re building cars or adding stuff to an engine. Occasionally people have errors to act on but mostly it’s goal oriented and ultimately the goals are vague. “I’d like my car to be a sports car.” or “I really want a good truck.”

          Neither of those things end up being precise and there are a variety of ways to achieve that goal depending on what you want. Do you want your sports car to be good at drag racing vs those twisty tracks? Your truck is for off-roading vs hauling dirt?

          I feel like there’s an initial ramp up that helps you think through some of these details (or even explains what a dump truck is) and then merges you into cPanel where you need to be taking action. I don’t know how possible that is but I do realize it’d be a lot of work.

          I’ve tried a number of times to blend conceptual goals, tools, and examples in ways that might make things more actionable for people. It’s never easy as there’s so much that happens that’s hard to capture.

          At other times I really wonder if it’s worth doing. Maybe you just give people the options/power. Have challenges that require the use of the options and just let things happen naturally. I didn’t think hard about choosing WordPress oh so many years ago. I just wanted to write on the Internet.

Leave a Reply

Trackbacks and Pingbacks on this post

No trackbacks.

TrackBack URL