Forem: Uclusion

Multiple tabs in your app

David Israel — Sun, 01 Nov 2020 01:57:47 +0000

Update 2024 use tab-election.

We had some problems with multiple tabs that are pretty common:

Writing to storage could collide or not get picked up
Logout in one tab would not be noticed in the other
Sync with the backend would be done independently by all

Being Uclusion we of course used a Uclusion Dialog to decide and the options were:

Pretty easy decision because in addition to using broadcast channel API when available the NPM package supported leader selection. That allowed us to set up a React context to let us know anywhere in the code whether our tab was leader or not - see code here.

We could also send messages to the other tabs telling them to refresh from IndexedDB like so

const myChannel = new BroadcastChannel(COMMENTS_CHANNEL);
      return myChannel.postMessage('comments').then(() => myChannel.close())
        .then(() => console.info('Update comment context sent.'));

Now the basic idea we followed was the leader syncs from the backend and stores in an IndexedDB namespace and all other tabs store their local edits in a differently named IndexedDB namespace. Its very unlikely more than one tab is doing local edits at a time and even if somehow they were the sync from the network is the eventual master.

Also very simple logout broadcasts a message which is listened for by the other tabs here

const [logoutChannel, setLogoutChannel] = useState(undefined);

  useEffect(() => {
    console.info('Setting up logout channel');
    const myLogoutChannel = new BroadcastChannel('logout');
    myLogoutChannel.onmessage = () => {
      console.info('Logging out from message');
      onSignOut().then(() => console.info('Done logging out'));
    }
    setLogoutChannel(myLogoutChannel);
    return () => {};
  }, []);

Traditional Kanban boards aren’t the best for stories.

Benjamin Follis — Tue, 06 Oct 2020 22:34:56 +0000

Kanban was developed for factory floors and operates best with tasks that don’t require additional discussion, are well defined, exist in discrete stages, and proceed in a continuous flow.

Bugs, and very small feature requests fit this model well, which is why Kanban is a popular methodology today with Trello and Github providing popular boards.

Unfortunately, every other kind of story doesn’t work so well. Stories that are part of larger work require frequent collaboration as the overall requirements evolve. Conceptually, such stories exist in discrete stages, but in reality stories influence each other: comments and suggestions abound, and traditional Kanban boards don’t have a way to display the true status.

What’s needed is a new type of Kanban board that integrates stories and communication. Suggestions during implementation should result in resolution during review, and failure to do so should be immediately apparent. Status needs to evolve from a simple column into a real-time view of what people are saying about the story.

Without such improvements, Kanban boards are not able to serve the needs of complex development, and will always be a source of frustration.

Development Collaboration is Complete Bullshit

Benjamin Follis — Mon, 05 Oct 2020 22:11:58 +0000

Developers are not ok with spending hours talking about out what to do next week
Daily standups are rarely actually useful
Backlogs are where things go to do die
Notifications and "responsiveness" are the modern equivalent to a dog leash
Video meetings with children running around are comically painful
Three people can agree on a meeting time, if two of them are dead
We're still dealing with "core hours" when nobody's life is that simple
Only estimating ahead of time doesn't even work for bathroom remodeling
Project management tools give managers what they want but not what they need
Engineers are judged on adherence to process instead of outcomes

What’s needed is a collaboration style that gives developers a seat at the table, without gluing them to their chair.

Backlogs don't make sense anymore

Benjamin Follis — Sat, 19 Sep 2020 00:13:17 +0000

Backlogs are the ordered list of items the team may take on in future sprints.

Modern customers expect short delivery cycles, and aren’t willing to wait for deliverables. In that environment, something that’s not getting done in the next sprint is the first candidate to drop when interruptions “blow up the sprint”.

Unfortunately this means that backlogs are where things go to die.

Maintaining the backlog requires the team to meet every sprint for at least an hour for “refinement”. This only pays off if the backlog items are worked on, which as stated above, is increasingly less likely. This is one of the reasons engineers tend to hate refinement meetings. They are tedious, and the return on time invested is horrible.

There is a better way.

Instead of a backlog of things that won’t get done, only keep track of stories that you’re going to do right now. When a story is created, assign it to a developer, and have the entire team weigh in on whether it should be done. Developers in turn, only start stories that their team considers worthy, and discard ones that don’t make the cut. In other words, continuously refine and plan, instead of waiting for the story to lose relevance.

Planning meetings are an exercise in futility.

Benjamin Follis — Thu, 17 Sep 2020 22:33:40 +0000

When sprint planning was first proposed software development cycles were measured in quarters or years. In that environment getting together to plan once every few weeks made a lot of sense, as the environment the software lived in wouldn’t be likely to change in that time.

That’s just not the case anymore, especially for online platforms. Software is deployed in weeks, or in some shops hours.

Creating a development plan for a fast release cycle costs too much.

Sprint planning is a significant investment of time and energy. The meeting requires everyone to get together for at least an hour, usually more. In order to make that investment pay off you have to speed up delivered software development by at least as many man hours. The shorter the sprint, the worse this ratio gets, and your process overhead goes through the roof.

Plans are unlikely to survive, even if sprints are short.

Traditional agile process has been a victim of its own success. Software delivery speed has gone up, and customers are no longer willing to wait months for a fix or for critical features to be developed. This means that whatever plans you make are increasingly likely to be interrupted by business needs. “Blowing up a sprint” isn’t a big deal if it happens once every few months, but it’s now happening all the time.

A better way is needed

Instead of trying to decide what’s getting done all at once, planning needs to happen all the time. Instead of building a backlog, when a story is created it is directly assigned to a developer, and the entire team weighs in on whether it should be done. Developers in turn, only start stories that their team considers worthy. When a story is blocked, before work starts again it must be considered alongside the new tasks that have arrived.
In other words, there’s no such thing as ‘blowing up the plan” only a succession of stories that are worth working on right now.

Enabling such a process is one of the goals of Uclusion, and we hope you’ll give it a try.

Standups used to make sense, they don’t anymore.

Benjamin Follis — Thu, 17 Sep 2020 01:22:19 +0000

Back when daily standups were conceived they were a good solution to waterfall development problems. Instead of working on their specification in isolation, everyone would get in a room and any issues would be surfaced before they got out of hand.

Unfortunately, they don’t really work well in the world we now find ourselves in.

The assumption that everyone is in the same room doesn’t translate well into online experiences.

Somebody, somewhere, is going to have a technical glitch, or forget to mute, or have a dog turn over the laptop. Unless everyone has a dedicated home office, it’s just not going to be possible to bring the same level of concentration to the meeting.

Once a day isn’t enough.

From the developer side, standups only really worked when we could have all the little conversations to clear blockages outside the standup. We don’t get those hallway conversations anymore, so the standup takes way longer than it should. You can try to keep that out of the meeting, but I’ve never seen it successfully done. Developers just want to help too much.

From the business side, the same lack of little conversations means that progress isn’t being made until tomorrow, and that utterly kills productivity. You can try to fix it by having more frequent group checkins, or a chat channel that should be monitored, but then you just wind up killing productivity because people are always getting interrupted when they need to focus.

There is a better way.

Instead of standups, what’s needed is continuous collaboration. Status isn’t something that exists at a point in time, it’s something that everyone should be able to see whenever they want. Questions and issues need to be reflected in that status, and should cause the appropriate people to be notified, instead of taking the entire team’s time.

Continuous actionable status is one of the things we’re trying to bring to life with Uclusion, and we hope you give it a try.

Uclusion React code now public

David Israel — Sat, 12 Sep 2020 16:21:51 +0000

In order to help with the learning curve in React, Uclusion uclusion_web_ui is now public with a Readme to many articles on Dev.To explaining its code.

I've been searching for a while now and am unable to find anything like this:

Public UI for a large recently launched React application that you can log in for free and use
Explained point by point with blogs and we are happy to add more if you request

Mattermost was the closest I was able to find and until their cloud beta finishes you have to setup a server to run them. With a Github or Google identity you are one click away from running Uclusion (and with any email several clicks) - no credit card required.

If you are new to React or even front end development in general then this repo and accompanying blogs are the resource I wish I had a couple of years ago. At the time we used Tarik Huber's excellent React Most Wanted which I also recommend but its no substitute for access to documented, easy to run, production level code.

React Wizards with State

Benjamin Follis — Fri, 11 Sep 2020 02:18:44 +0000

Hi,
Over at Uclusion, we have a fairly large amount of information required to properly set up a Workspace (or Dialog, or Initiative). As we talked about in Wizards aren't just for Hogwarts, to make sure our users aren't hit with too much information at once, we've converted all of our top level creation flows to Wizards.

While doing so we discovered that the most annoying part was keeping track of the form state that the user had entered, and making sure the user could resume if they had to reload or just set down work.

To make sure YOU don't have to go through the same annoyance, we're open sourcing react-formdata-wizard, which will maintain all the state transitions, form data, resets, etc, all in one easy to deal with package.

Unlike other react wizard projects we do not render any UI or nav buttons, but instead provide you with the properties you need to make your own. That keeps state management separate from UI, the way it should be.

Enjoy, and expect more changes as time goes on. We're busily rebasing the entirety of the wizard flow on this package.

Responding to Mr. Hastings statements about WFH

David Israel — Wed, 09 Sep 2020 18:57:37 +0000

Imagine a world like ours suffering a pandemic but there are no streaming services. The movie theaters shut down and people are forced to watch entertainment from the internet in any way they can cobble together.

Now along comes someone and says watching from home is "a pure negative".

Mr. Hastings says, "Debating ideas is harder now." just as in that alternate no streaming services world someone might say, "full immersion in the entertainment is harder now."

Of course without streaming services one would have no concept of binge watching and so watching from home would have less upside. Just as in a world where working from home tools like Uclusion are unknown it might seem that asynchronous collaboration is very difficult.

Early on in any technological change skeptics can poke fun. The real surprise is a visionary like Hastings having so little vision on this subject:

If I had to guess, the five-day workweek will become four days in the office while one day is virtual from home. I’d bet that’s where a lot of companies end up.

Why not four days virtual from home and one day in the office? If WFH is such a negative why would people want the one day from home? America is very early on in this experiment and already working remotely is working much, much better than predicted. As new technology built for asynchronous collaboration becomes more wide spread the case for a high percentage of time in the office will only decrease.

How Uclusion Makes Life Easier for the Team Lead

David Israel — Fri, 17 Jul 2020 00:32:41 +0000

As a point of departure let’s use Lane Wagner’s observations on four problems faced by current common process:
Leave Scrum To Rugby - 4 Major Issues With Using Scrum | Hacker Noon
*Bitcoinist, libertarian, atheist, cryptography fan, and founder of http://qvault.io Scrum is a buzzword, the virtue…*hackernoon.com

Problem #1 — Scrum Is Vague

Here’s how Uclusion’s built in workflow and rules make the state of development crystal clear:

At a glance, Dene Jille’s story in Proposed is not approved yet (red text), her story In Progress is on track, her story in Review has unresolved comments (red text), she is Blocked on “Map software” story and Requires Input on “Naming and domain” story.

This is all backed by Uclusion enforcing only one story In Progress at a time and opening a blocking type comment automatically moving the story to Blocked. Also, Opening a Dialog on a story automatically moves it to Requires Input, and if a story is past its estimated completion date then Dene has to enter a progress report or the whole card shows yellow.

Problem #2 — The “Sprint”

Sprints don’t enable agile software delivery — they crush agile altogether unless you live in some dinosaur world where collaboration can wait to happen once every two weeks.

Uclusion Workspace with a new edit showing a highlighted diff

Uclusion works a different way.

Don’t maintain a backlog of fully flushed out stories that may or may not be ever implemented. Instead keep your requirements in a wiki like area in the Workspace. When the requirements are changed everyone will be notified and see a diff.
A developer or team lead will write up a story from the list of requirements and assign it.
The story will be in Proposed and one or more members of the team can approve it

If you really want every single team member to estimate and approve the story then there is a Workspace setting for the number of approvals required — change it to the size of your team. The important thing is that the approval, implement and review cycle in Uclusion is truly continuous — not on arbitrary Sprint boundaries.

Problem #3 — The Scrum Master

Effectively Uclusion has automated some of what was perceived as a Scrum master’s job.

Uclusion notifies everyone so a Scrum master does not have to

However fully agile software delivery has a lot better things for a process person to do. With the team at full speed and potentially changing direction more often the work shifts to helping get everyone on the same page. Here is where Uclusion’s structured communication shines:

Opening a TODO on a story prevents it from changing stage until the TODO is resolved.

Options for doing a story get their approval right inside the story. Now when the team lead or process czar wants to keep things moving he can see exactly what the issues are and, if necessary, call meetings that have an agenda that makes sense.

Problem #4 — Estimates

In Scrum you don’t even write down people’s individual opinions.

Much of the Scrum ceremonies are data for the sake of data instead of being actionable. If your burn down chart looks bad or Sprint estimates are wrong what are you going to do about it? Most likely have a retrospective meeting where nothing is resolved either. Instead of a traditional retrospective Uclusion recommends opening a Dialog and doing something with about it now — not 2 weeks later.

Its just easier

If you are a team lead insist on a process and supporting collaboration tool that matches the way software is built in 2020. We think Uclusion is that tool and would love to talk about it — https://calendly.com/uclusion/30min.

Getting the highest ROI out of Contractors

David Israel — Tue, 14 Jul 2020 21:38:57 +0000

Uclusion, works a lot with contractors. If you’ve ever done so yourself, you understand that the single biggest problem is making sure that the contractor is constantly doing useful work.

We believe that the features we describe below are the minimum requirements for any product which is going to help you get good ROI from your contractors.

Contractor “Swim Lanes” (personalized Kanban boards), are right on your home page.

Approval for a story requires value to be assigned to a story.

If the story is taking more time than estimated we will demand a progress report from the contractor and mark the story as in danger.

When your contractor raises a blocking issue on a story, you will be immediately notified, and will see it in the swim lanes.

You can provide, TODOs and the contractor can’t move the story forward until they do what you tell them.

It’s clearly visible when a story needs your input.

Communication resides inside the story, not outside of it.

You can easily communicate with images and files, not just text.

It is possible to effectively manage contractors without spending inordinate amounts of time or effort. However to do so you need a tool like Uclusion, or you’re going to see significantly lower ROI than you could be.

Is Testim worth using for automated testing?

David Israel — Fri, 10 Jul 2020 19:50:37 +0000

For the past couple of weeks, I have been using Testim.io as a tool to create tests for the company Uclusion’s user interface, so it’s safe to say I have a pretty good impression on the site’s capabilities. In short, it’s a mixed bag. The amount of struggle you’ll have in Testim entirely depends on what you’re testing. Testim excels when you bug-test simple things, like the Google Calculator: the test making process and run-through are notably smooth . But when you try to use it for full-blown websites, like the Uclusion.com site I’m working on now, …not so much. Here is a list of its strengths and weaknesses, so you can decide whether Testim is the one for you.

Strengths:

“Educate” on top, support on bottom.

Great customer service. If you have a question or concern, on the upper right, they have an “educate” button that answers a variety from frequently asked questions, from basic to expert. If you can’t find what you’re looking for in there, you can contact their support team, who respond in a couple of minutes. They are a really nice group of people who try to answer anything problems you have.
Easy to use. Pictures 2 and 3 on the bottom left is a test I made for Uclusion, where it tests its Google sign up option. As you can see, it allows groups, which are very useful for reusing steps, making the test creating process significantly faster. Once you have created the test, the run through is very straight forward, telling you exactly where it messes up (if there is an error that is). Testim is very comparable to coding. It will do exactly the instructions you give it. The instruction making process is very simple: all you have to do is perform an action, and Testim will record it and replicate it as an instruction. Just remember whatever you do when recording, you’re doing in an actual browser.

Picture 2 (An array of subsequent groups)

Weakness:

Picture 3 (The steps inside a group)

Major lack of flexibility. All of Testim’s weaknesses stem from this, so instead of having a long list of each individual weakness, I’ll try to summarize my problems so far. When I said the instruction making process is simple, I didn’t necessarily say it was good, or flexible. If you intend to use it as a legitimate website testing tool, this is where you’ll run into problems. You are extremely limited in what actions you can perform. For example, Testim doesn’t have a function where you can navigate through Google accounts without programming. It will also be unable to catalog links. If you copy a generated link, Testim will generate a step where it continually navigates to that specific link you clicked, rather then the general “copy and paste generated link” step you probably intended. In short, if you try anything that is the slightest abnormal Testim will either be unable to create that action for you, or be inconsistent in the test running process.