Jess Boctor

Tag: WordPress

  • In Pursuit of Clarity of Thought

    Recently, I have found myself feeling nostalgic for P2. P2 is a tool crafted by a previous employer that allowed documentation and communication across teams. The micro-blogging product allowed long form discussion to happen by being easy to use, having tags for individuals, a robust notification system, and making most things searchable. It was a verb as much as a product. The company culture was embedded with it, to the point that “If it isn’t in P2, it doesn’t exist”.

    As someone who has kept a journal for more of my life than not, writing out my thoughts has always been a way to process what is happening and next steps. Aside from the in-the-moment-brain-dump benefit, these writings have acted as record keepers. I can piece together how I got where I am today by seeing where I was before. Oftentimes, passing of time and new experience allow me to look back at an earlier period of my life with a different insight. Patterns and issues I was blind to become illuminated with a reflective perspective.

    Currently, my day-to-day work is heavy in interaction with LLMs. It feels like I am writing more than ever. At the same time, it seems easy to lose the context thread. I keep finding myself wishing for a place to look back, a desire to just “P2”.

    When I stopped to examine why, more than a year later, I still feel the loss of this tool, I realized it was more about a practice than it was about the tool.

    Long form writing forces clarity of thought.

    My opinion is that LLM’s encourage brevity. The harnesses and UIs that allow us to interact have short message boxes. The prompting and direction are meant to be a conversation. The models themselves do better with specificity over vagueness.

    P2, blogging, and journaling all force me to stop and think long enough to create a fully fleshed out piece of prose. This pausing, writing, and editing cycle creates a more distinct picture not only for the reader, but in my own mind. The action of fully describing a problem can often illuminate its solution, often called rubber-ducking in the tech world. And, of course, there is the aphorism that you don’t really understand a topic until you can teach it, or for my illustration, write about it.

    So here are some rituals and communication hygiene I am experimenting with to make sure I don’t lose clarity in pursuit of speed.

    1. Stop, drop, and prompt — I am instructing my agents to push back every time I start a new session. They should drop the shortened session start message and ask for a more in depth version. The pushback will require me to describe the prompt more fully, giving me time to really clarify the issue for myself and the agent.
    2. Pay attention to one session at a time — I often find myself jumping between multiple session threads. It gets easy to do when you the current agent session is working and you can just open a new tab to start a second thread. The goal isn’t to stop concurrent agent work but to stop context switching in the middle of a task.
    3. Maintain an un-siloed context stash — I have a journal for each customer (the main context I am responsible for) with dated MD files. Decisions, communications, and working sessions all get a note. It doesn’t have to be comprehensive, it just has to track the history of the customer in one place. This is all stored in a place where anyone from the company can access it.
    4. Encourage adversarial agents — I work in a small company. Oftentimes, the only eyes on work in progress are my own. Rather than having agents who passively agree, I encourage them to challenge what I prompt.

    I don’t think that P2 is the right tool or culture for every company, but I know the ritual of long form writing is beneficial to me and my work. I am finding my own way to implement clarity in daily life.

    If P2 sounds interesting an you would like to experiment with a P2-like product, another nostalgic A8c alumni has created a version you can manage on your own: https://github.com/georgestephanis/p2026

    Or you can sign up for the hosted version at https://wordpress.com/p2

  • Making a SCUD Plugin

    I am working with a company who needs a nicely formatted way to display a group of employees. Currently, the team page is using hardcoded [author] shortcodes to format the page, but this makes it a pain for the staff to update the team information.

    So they don’t.

    So, I am creating a Simple Custom User Display, or SCUD, plugin.

    Did you think I was talking about missiles? Also, did you know there is a type of baby shrimp called a scud? You can learn about them here.

    I am sure there are already WordPress plugins which have a similar functionality to display users in a page archive. However, in this case, the company that I am working with doesn’t need a bunch of bells and whistles. Since they don’t have someone who regularly handles updating the site, keeping things light and less likely to run into update conflicts would be best.

    Also, I haven’t built a plugin from scratch in a bit. The majority of my recent work has been in digging through legacy code and surgically making improvements and refactors. Building something new seems like fun.

    Before I started writing any code, I spent some time thinking through the plugin and what this company needed. I thought it might be an interesting exercise to share.

    Problem Statement:

    The “Company” needs to improve their current “Team” page. Currently, it is out of date and is not easily updated by the staff at the Company. The current page is making use of the [author] shortcode in order to format contact information which is hard coded into the page directly. The metadata for each team member is not being pulled from a custom post type or user profile. This means that in order to edit a single piece of information (e.g. update a team member title), the user must sort through the page code to make changes.

    Solution:

    Create a lightweight plugin which uses as much core WordPress functionality as possible to make each team member information its own dataset. This way, the team member information can be easily pulled, sorted, filtered, and displayed on the front end. To make this easily editable in the future, utilize WordPress users to contain the sales rep information and metadata.

    Information store: Users

    The current website displays the team members grouped by their team and state. We can maintain this information if we can create a taxonomy for users. This looks to be a simple case of registering a custom taxonomy on the user type

    After creating the taxonomies, we want to limit the capabilities of the team member users. We can do this by creating a custom user role “Team Member” and limiting what they have access to. The role needs to only be added during the activation hook of our plugin and then we can begin to assign users to the role.

    The last piece of information we need to include is custom user meta fields. The team members have extra information, like their title and regions, which we need to be able to save. We can include this in the edit_user_profile hook

    The end goal here is that any team member could log in to edit their own profile information. If they don’t have their login, an administrator would also be able to update the contact information for them.

    Display

    Option 1: DataViews (Stretch)

    WordPress has recently introduced DataViews to core. This allows data sets (such as users) to not only be displayed, but also searched, filtered, and sorted. 

    DataViews has multiple layout options, including a table, grid, or list. Since the DataViews fields each render the component in custom React, we can customize the layout of the user information and how it is displayed.

    Additionally, since not all “fields” have to be displayed to be used for filtering, we can use the taxonomies to filter the users.

    The goal here is to allow users to be added to the website and then be automatically added to the Sales Team page without needing to edit the page content itself.

    If we contained the DataViews within a Block (for Divi or Gutenberg) then we would also be able to add custom content above or below the block without having to touch code.

    Divi can now display Gutenberg blocks. So this means we only need to create the block as part of Gutenberg.

    Option 2: Page Template

    This is basically the same principle as option 1, but with a custom page template. This is less flexible and doesn’t allow for searching, sorting, or filtering.

    Option 3: Divi Drag and Drop Page

    This option would be the most similar to the current implementation (the layout being created within the page editor). While we would still have the benefits of better user information control, it wouldn’t solve the long term-ease of use problem. It would likely be the least time consuming though.

    I am developing a boiler plate version of this plugin here: https://github.com/JessBoctor/simple-custom-user-display

    The goal is not to create a WYSIWYG plugin which allows a user to install and customize the new user role and display. Rather, it is a lightweight plugin with enough instructions on how to customize things that a dev can pick it up and make it their own.

    Which is what I will do for the company I am working with 🙂

    PS Before and after images will be coming soon once I have the website refresh completed.