Forem: David Israel

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 () => {};
  }, []);

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.

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.

How Teams Work with Uclusion

David Israel — Tue, 07 Jul 2020 21:28:23 +0000

We’ve all seen that email is too silo’ed; important discussions get trapped and never see the light of day. However group chat has gone too far in the other direction:

Put the message in a #channel
Even if a Slack message is directed to one person, it should be posted in the appropriate channel and not via DM. Most of our channels correspond to a project, so you never know when another team member might need that information in the future. Following this rule has transformed Slack into a valuable archive that’s simple to search.

I’m not going explain why that’s madness — by now everyone has experienced that kind of garden hose of notifications and information and already knows all too well.

Uclusion recommends a different approach to sharing information with those that are not directly involved in your project:

Put read only links to Uclusion stories into your code
Put read only links to Uclusion Workspaces into a Team Workspace

To create a team Workspace

choose the first option above and name the Workspace with your team designation. Now invite everyone on your team to the Workspace.

Members of your team probably already have different projects they are working on in Uclusion Workspaces. For instance “V3 API”:

You’ll want to choose “Share a read only link” as you see above and then paste that link into the description of your team Workspace (the link will automatically have the name “V3 API” applied to it).

After everyone on your team has pasted in the Workspaces they are involved in you can share a read only link to this team Workspace for all to know what your team is doing. And since everyone on your team is a collaborator in the team Workspace they will be notified of all changes.

But that’s not all, in the past when you wanted to change your team process perhaps you had a retrospective meeting or a long email chain. If that is working for you then continue on, otherwise choose “Add Dialog”

and state the problem and possible solutions there:

Finally team level discussion can use the team Workspace’s structured communication options

How Product Managers Work with Uclusion

David Israel — Tue, 07 Jul 2020 18:49:38 +0000

Sometimes the terms collaboration, brainstorming and empowerment get mixed up and since Uclusion is a great tool for all of them it can be confusing. Collaboration is “the action of working with someone to produce or create something.” Even if a PM provides all details its still collaboration and its still hard. Explaining in English precisely enough that computer code can be written makes PM / engineering communication a real challenge.

On top of which customers can be indecipherable, priorities change and technical realities intervene. That’s why a Uclusion Workspace is a great place to collaborate on requirements

When you change requirements everyone will be notified and automatically see a diff

That’s a lot easier than entering a separate backlog item for every single requirement and much easier to maintain.

You receive notifications and see highlighting for the structured comments entered about the requirements and comment can be resolved when addressed.

Once the requirements are understood engineers can start creating stories based on those requirements right in the same Workspace.

When someone needs help on how a story will be implemented you will be notified and it shows in a separate section of the Uclusion swim lanes

The options you need to weigh in as the PM are discussed and approved right inside the story

Instead of a long ambiguous email thread or group chat everyone knows exactly what was decided and how.

If you need a rough idea of when the requirements in the Workspace will be complete ask the engineering team to maintain the Workspace date of completion field. That displays right alongside the requirements you have input and you will be notified if it is changed.

And if you need to go back to customers for clarification don’t start one of those long ambiguous email threads with them either. Use a Uclusion Dialog instead.

Integration Tests, Promises and Websockets

David Israel — Sat, 27 Jun 2020 17:01:49 +0000

Uclusion is powered by an eventually consistent Rest API and uses WebSockets to inform the client when data changes server side. This means that any integration test that depends on writes happening in a sequence must integrate web sockets into it’s control flow.

More specifically, the integration test must integrate web sockets in a way that allows for messages to arrive in any order, and must fuse the WebSocket notification with the standard Promise based control flow that our SDK presents.

So how do we do this? With a WebSocket “runner”:

import _ from 'lodash';
var W3CWebSocket = require('websocket').w3cwebsocket;

/**
 * Class which fires and manages a websocket connection to the server. Copied from and derived from the uclusion web ui code
 */
class WebSocketRunner {
    constructor(config) {
        this.wsUrl = config.wsUrl;
        this.reconnectInterval = config.reconnectInterval;
        this.subscribeQueue = [];
        this.messageHanders = [];
    }

    getMessageHandler() {
        const handler = (event) => {
            //console.log(event);
            const payload = JSON.parse(event.data);
            //we're going to filter the messagehandlers at each run
            //and if they return true assume they want to go away
            this.messageHanders = this.messageHanders.filter(messageHandler => !messageHandler(payload));
        };
        return handler.bind(this);
    }

    /**
     * Subscribes the given user id to the subscriptions described in the subscriptions object
     * subscriptions is an object of a form similar to
     * @param idToken the identity token to subscribe too
     */
    subscribe(idToken) {
        const action = { action: 'subscribe', identity : idToken };
        // push the action onto the subscribe queue so if we reconnect we'll track it
        this.subscribeQueue.push(action);
        // if socket is open, just go ahead and send it
        if (this.socket.readyState === this.socket.OPEN) {
            const actionString = JSON.stringify(action);
            this.socket.send(actionString);
        }
        // compact the queue to remove duplicates
        const compacted = _.uniqWith(this.subscribeQueue, _.isEqual);
        this.subscribeQueue = compacted;
    }

    onOpenFactory() {
        // we have to assign queue this to prevent the handler's
        // this from being retargeted to the websocket
        const queue = this.subscribeQueue;
        //console.debug('Subcribing to:', queue);
        const factory = (event) => {
          //  console.debug('Here in open factory with queue:', JSON.stringify(queue));
          //  console.debug('My socket is:', this.socket);
            queue.forEach(action => {
                const actionString = JSON.stringify(action);
                //console.debug('Sending to my socket:', actionString);
                this.socket.send(actionString);
            });
            // we're not emptying the queue because we might need it on reconnect
        };
        return factory.bind(this);
    }

    onCloseFactory() {
        const runner = this;
        const connectFunc = function (event) {
            //console.debug('Web socket closed. Reopening in:', runner.reconnectInterval);
            setTimeout(runner.connect.bind(runner), runner.reconnectInterval);
        };
        return connectFunc.bind(this);
    }

    // dead stupid version without good error handling, we'll improve later,
    connect() {
        this.socket = new W3CWebSocket(this.wsUrl);
        this.socket.onopen = this.onOpenFactory();
        this.socket.onmessage = this.getMessageHandler();
        // make us retry
        this.socket.onclose = this.onCloseFactory();
    }

    /** Waits for a received message matching the signature passed in
     *
     * @param signature an object of key/value pairs we'll wait for
     * @return A promise that resolves if the message is received within timeout milliseconds,
     * otherwise rejects
     */
    waitForReceivedMessage(signature){
        return this.waitForReceivedMessages([signature]).then((responses) => responses[0]);
    }

    /** Waits for a received messages matching the signature passed in
     *
     * @param signatures an array of object of key/value pairs we'll wait for
     * @return A promise that resolves if the message is received within timeout milliseconds,
     * otherwise rejects
     */
    waitForReceivedMessages(signatures){
        console.log("Waiting on message signatures:");
        console.log(signatures);

        const promises = signatures.map(signature => {
            return new Promise((resolve, reject) => {
                //     const timeoutHandler = setTimeout(() => { reject(signature) }, timeout);
                this.messageHanders.push((payload) => {
                    console.log("Received payload for matching:");
                    console.log(payload);
                    let stillMatching = true;
                    console.log(IT"Testing message against signature:");
                    console.log(signature);
                    for(const key of Object.keys(signature)){
                        stillMatching &= (payload[key] === signature[key] || isSubsetEquivalent(payload[key], signature[key]));
                    }
                    if (stillMatching) {
                        console.log("Found match");
                        //            clearTimeout(timeoutHandler);
                        resolve(payload);
                        return true;
                    }
                    return false;
                });
            });
        });
        return Promise.all(promises);
    }

    terminate(){
        // kill the reconnect handler and close the socket
        this.socket.onclose = (event) => {};
        this.socket.close();
    }
}

function isSubsetEquivalent(payload, signature) {
    if ((!payload && signature) || (!signature && payload)) {
        return false
    }
    for(const key of Object.keys(signature)){
        if (payload[key] !== signature[key]) {
            return false;
        }
    }
    return true;
}

export { WebSocketRunner };

In general, the WebSocket runner above presents a function waitForReceivedMessages that allows the caller to register a signature and returns a promise that will resolve when a message comes in over the wire that matches the signature. A message is considered to match, if all fields in the signature match the corresponding fields in the message. Note, however, that a message may have more fields than the signature, which allows us to only give signatures for the things we consider important in the message.

Usage of the runner proceeds as follows:

....
}).then((messages) => {
    const userPoked = messages.find(obj => {
        return obj.type_object_id === 'USER_POKED_' + adminId;
    });
    assert(userPoked.text === 'Please add the thing.', 'Wrong poke text');
    return userClient.users.removeNotification(adminId, 'USER_POKED', createdMarketId);
}).then(() => {
    return userConfiguration.webSocketRunner.waitForReceivedMessage({event_type: 'notification', object_id: userExternalId});
}).then(() => {
....

Your situation may require two-way communication via the WebSocket. In that case I would model the message transmission from client to server as a promise, which will allow you to serialize your communication sequences much like we do with our Rest API.

That’s about it, and I hope this helps you along your testing journey.

Designing SaaS Rest APIs for web clients

David Israel — Tue, 23 Jun 2020 21:54:14 +0000

For a typical browser IndexedDB storage gives you access to as much as half the free disk space. Once you convince yourself to use Rest, having that much storage makes your basic flow:

Have an API that returns all changed items for a client.
Have APIs that return the items for anything that changed.
Any create or update API will need to return the back end stored object so that the front end can update its IndexedDB cache.
In general do not expose individual item read APIs or APIs that filter, sort or search — do all of that on the web client.

In graphical terms 1 and 2 look like this:

So far very simple but 3 is where we fall down the rabbit hole. If any single one of your APIs is eventually consistent then answering “Client up to date?” is hard.

Uclusion uses DynamoDB and asynchronous workflows built on DynamoDB streams so of course there is eventually consistent everywhere. Even with a SQL DB you could be reading from a slave or multi-master database where replication lag will be eventually consistent. If you rely on a read immediately following a write returning the data you just wrote then the front end client is dictating back end implementation.

If because of client space or compute limitations filter, sort and search capabilities must have APIs then run them outside your main transactional database. Otherwise long running queries against the same database requiring lightning fast create and updates is a use case mismatch. So these kinds of querying APIs require eventual consistency as traffic and volume of data scales.

With eventual consistency a call to refresh the client with the latest data can overwrite newer data that it already has from create and update operations. So a user might see his newly created object disappear for a while unless you are careful.

Traditional CRUD where a page loads from the back end dynamically or hoping to get by with an all synchronous API are strategies that user performance expectations and SaaS traffic loads have obsoleted. Our strategy for handling syncing eventually consistent objects:

All objects are versioned and these versions are used for signatures.
When the back end sends the object signatures it records an ID in a look up table for what was sent to the client.
If the client is successful in retrieving the object signatures it uses the signature ID in subsequent calls to inform the back end what object versions it has.

Notes on S3 backed File Downloads

David Israel — Fri, 19 Jun 2020 21:09:41 +0000

Uclusion recently introduced arbitrary file uploads to our Workspaces or Stories (we previously allowed only images), and there are a few implementation notes I’d like to record for posterity.

Firstly, browsers do not always provide a content type when uploading a file. If your backend demands content types the code something like the below is needed when asking for a presigned post

export function uploadFileToS3 (marketId, file) {
  const clientPromise = _.isEmpty(marketId) ? getAccountClient() : getMarketClient(marketId);
  const { type, size, name } = file;
  // if we don't have a content type, use generic octet stream
  const usedType = _.isEmpty(type)? 'application/octet-stream' : type;
  return client.getFileUploadData(usedType, size, name))
    .then((data) => {
      const { metadata, presigned_post } = data;
      const { url, fields } = presigned_post;

See production file with this code.
Second, unless your served JS or HTML is coming from the same domain as your CDN, browsers will happily ignore the download attribute of S3 links. They will either open it in a new tab with their viewer, or, for security reasons, use the S3 bucket’s file’s name. This means that if you machine generate paths such as https://dev.imagecdn.uclusion.com/8432f156-f452-4031-8e7d-728deb25f7cd/35fed849-1b69-4f05-9cea-99f57d5f71e9 the user will end up with a file of 35fed849–1b69–4f05–9cea-99f57d5f71e9.

To avoid this, set your content distribution on your presigned post. This won’t effect the downloaded path, but is a method of telling the browser what you want the downloaded filename to be. Here’s code that does that, and also attempts to set the extension on the path appropriately:

def post_validation_function(event, data, context, validation_context):
    content_length = data['content_length']
    original_name = data.get('original_name', None)
    content_type = data['content_type']
    file_path = str(uuid.uuid4())
    # See if they provided the original name,
    # and if so use it, and try to put a good extension on
    fields = {"Content-Type": content_type}
    if original_name is not None:
        fields["Content-Disposition"] = 'attachment; filename="' + original_name + '"'
    extension = guess_file_extension(content_type)
    if extension is not None:
        file_path = file_path + extension

    used_id = validation_context['market_id'] if validation_context['market_id'] is not None else validation_context['account_id']
    path = used_id + '/' + file_path
    return create_post(path, fields, content_type, content_length, bucket)


def create_post(path, fields, content_type, content_length,  bucket):
    expiration = 60  60  24  # Upload must occur within 24 hours
    conditions = [
        ['content-length-range', content_length, content_length],
        {'Content-Type': fields['Content-Type']},
        {'Content-Disposition': fields['Content-Disposition']}
    ]
    post = s3_client.generate_presigned_post(bucket,
                                             path,
                                             Fields=fields,
                                             Conditions=conditions,
                                             ExpiresIn=expiration)
    return {
        'metadata': {
            'path': path,
            'content_length': content_length,
            'content_type': content_type
        },
        'presigned_post': post
    }

Notice that I set the constraints to include all Fields. If you don’t do that your users will get Access Denied whenever they try to upload.

If you don’t mind the users getting generated names, then I would at least attempt to set the file extensions properly. The code above invokes the following function to do so, and extension setting is one of the reasons why we demand content-type to be passed in when doing a presigned post.

import mimetypes

# Constants to give the file upload some additional information on extensions, especially on MS mimetypes
#
MS_TYPES = {
    'application/msword': '.doc',
    'application/vnd.openxmlformats-officedocument.wordprocessingml.document': '.docx',
    'application/mspowerpoint': '.ppt',
    'application/vnd.openxmlformats-officedocument.presentationml.presentation': '.pptx',
    'application/vnd.openxmlformats-officedocument.presentationml.template': '.potx',
    'application/msexcel': '.xls',
    'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet': '.xlsx',
    'application/vnd.openxmlformats-officedocument.spreadsheetml.template': '.xltx',
    'application/msproject': '.mpp',
}


def guess_file_extension(mime_type):
    lowercase = mime_type.lower()
    system = mimetypes.guess_extension(lowercase)
    if system is not None:
        return system
    # the system doesn't know, try our MS map
    return MS_TYPES.get(lowercase, None)

An Opinionated Review of Asynchronous Team Collaboration Tools for 2020

David Israel — Tue, 16 Jun 2020 22:37:06 +0000

The opinionated part is that this review assumes the main purpose of team collaboration software is to serve the communications needs of the team using it. If you are more in the market for a tool that organizes across projects and teams, focuses on reporting productivity or tracks hours billed then this review will not be as useful. You have to have a main purpose in mind when you choose your team’s tools because software that does it all would be too complex to do any of it well.

Here we’re also going to assume that your video conferencing and direct messaging needs are out of scope. I don’t think the addition of synchronous communication will make a big difference in your choice of asynchronous tools. Most likely the best in class asynchronous team collaboration tool wins regardless of whether or not it has integrated video conferencing and synchronous messaging.

Uclusion

Where do your requirements go?

In a workspace’s description:

Somewhat like Wiki when the description changes everyone will be notified and see a diff.

Where do your stories go?

In swimlanes showing what each person in a workspace is up to. Note that you can only have one story in progress per Workspace and so you always know what is actually being worked on.

Where does your communication about requirements and stories go?

Structured, resolvable comments in a workspace or story. If you open a blocking comment it blocks, a TODO must be closed before changing stage, etc.

You can also reach a decision about requirements or implementation of a story in a dialog:

Finally you can kick of a new project or direction by launching an initiative which has up down voting with certainty and reasons:

How do you know what everyone has done, will do now and will do next?

The swimlanes shown above already display at a glance what everyone is up to but in addition you are prompted to vote certainty, days estimate and reason on the assignment of a story right inside the tool without having to have additional meetings.

Trello

Where do your requirements go?

In cards on a Kanban board. According to Trello it would look something like this:

From https://trello.com/en-US/teams/engineering

Where every requirement, no matter how small, gets its own card in an ever growing backlog.

Where do your stories go?

Same place.

Where does your communication about requirements and stories go?

Inside a card.

Seriously?

How do you know what everyone has done, will do now and will do next?

Trello recommends the daily updates power up:

I’m not making this up

Trello + Slack

Like the Trello solution except now some of your messaging will no longer be co-located with the requirement or story it is about and instead scroll up the screen hoping to be noticed before it disappears.

Trello + Slack + Google Docs

We asked someone what they liked about this solution and they said, “Everything integrates well with each other.”

Azure DevOps

Where do your requirements go?

Kind of laborious but you could put the requirements in an Epic and then link Issues to the Epic:

Where do your stories go?

Following the above idea (Azure DevOps is non-opinionated software) they go in issues and issues have their own Kanban display like above.

Where does your communication about requirements and stories go?

Rudimentary commenting inside the cards like Trello.

How do you know what everyone has done, will do now and will do next?

Filter the Kanban board by assigned. You can add columns to the Kanban board and you can also add what is called swimlanes to the columns (like a subcolumn). However this approach is unlikely to tell you much because Azure DevOps encourages backlogs. So its a bit like looking at someone’s email Inbox to figure out what they are doing.

Essentially Azure DevOps, Jira, Linear and others are designed for issue tracking - smaller, potentially customer driven, problems that are less about approval and design and more about cranking out on a schedule. Using an issue tracker is a good idea for anything that does not require much collaboration.

Asana

Same as Trello in use of a Kanban board but comments inside a card look like this

and if you want to know what people are up to you apparently create a whole different Kanban board and search inside each card one by one.

Monday.com

Less of a collaboration tool and more of a pre built spreadsheet:

Clubhouse

Less of a collaboration tool and more like a database barfed on you. Do your requirements go in an Epic or a Project? Or maybe you use a Workflow?

Supposedly there are swim lanes like Uclusion has but after 30 minutes of really trying I was unable to get them to show. The way to compete with Jira is not by being more complex.

Zepel

Where do your requirements go?

In their own list:

Where do your stories go?

On a Kanban board which is a different view of the requirements list:

Where does your communication about requirements and stories go?

A requirement and the story to do a requirement share a card so you can comment inside of it:

How do you know what everyone has done, will do now and will do next?

I wasn’t able to find any way to do this. You can generate a burn down / up report

but going back to our opinionated purpose how is this report actionable for the team doing the work? It doesn’t say who is blocked on what or give any indication of progress reports etc.

Favro

Again the opinionated issue comes up — are we optimizing for ease of development or ease of reporting? Or put another way is it more important that stories get done or that they get done on a certain timeline?

There could well be situations where the timeline is the more important factor. For instance suppose this is a situation where zero creativity is required and success is solely dependent on speed of doing a multitude of straight forward tasks.

Microsoft Teams

According to Microsoft support you can add a Kanban board by

Teams literally does everything — chat, boards, wiki, conferencing, screen sharing, you name it. Reviewing it as a solution is like reviewing a laptop as a team collaboration tool; a team that collaborates is likely to have laptops and they also may be using Microsoft for something.

Notion

Similar to Teams but even more so Notion is more like a high level programming language for collaboration applications. Excellent if you want something specific that you are willing to build yourself or you want to share finished content that you worked on by yourself.