Original WebApp Design:

This is just about exactly what it looks like now:

Visual Design

In terms of overall design, so long as all the Needs and most of the Really Wants are there, and it looks decent, the design can be anything.

Need-to-Have's:

• Log In/Out:
  • Authentication is not so much of an issue as being able to track what use is performing what operations (for metrics). Ideally it would be nice to have "guest" functionality so that anyone could mess around with it without making an account. Maybe guests could only interact with the webpage and not be able to do anything that publishes to AWS?
• Operation Selection
  • Need to be able to view the capabilities of the app as well as utilize them. Right now this is implemented with simple buttons and text fields, but ideally it would look a littler bit nicer. Todo: explain more what I mean and come up with a direction to improve (see Update Neopolitan problem)

Really-Want-to-Have's:

• Connection Status
  • It's nice to see whether the application is actually connected to AWS. Might be a good idea to include a tooltip or something to show what that green dot means
• Connected Devices
  • It's cool to see that there are devices on the other end actually listening to what's going on (in addition to being a useful tool for debugging
• Some form of error display
  • Right now, this is the "MQTT Log", which is useful for debugging purposes but doesn't look very nice. Ideally, instead of these text logs there would just be some sort of error message when things don't work (MUI has some nice ones)

Nice-to-Have's:

• About Page
  • Explain why this project was created, what purpose it serves, and some "fun" architectural challenges that were encountered
• Board Display
  • Really would like this, but not MVP. It would be neat to implement the Python code for neopolitan within JavaScript somehow so that users could see an instantaneous representation of their operations. This extends to some visual for all operations as well (ex a "turn on lights" operation would have a gif of a lightbulb turning on), but that increases complexity dramatically.

App Functionality

What does it need to do, in the end? See project proposal.

Where Does That Leave Us?

Victor todo/direction

• styling
• break into components/organize app structure
• better documentation?? what files need it? tradeoff between everything having doc comments and making the code readable without

The Update Operation Issue

This part is a WIP. Maybe by writing it out I'll actually figure out how to solve the issue.

Sending just commands is simple: either a) publish to a command-specific route or b) publish to a general commands route with a payload that specifies the command (how the application is currently designed). Originally the project was built to handle payloads that specify one operation and one piece of data. The question is: What if we need to send a larger piece of data? For example, sending a command that prints to the console is simple:

export const echoCommand = { // command payload
  topic: topics.commandTopicResponse, // topic to send a success/failure response back to
  action: { // action/operation data
    cmd: 'say', // indicate that you want to print/echo something
    data: 'hello' // the text to print/echo
  }
};

as is sending a command that runs the Neopolitan Test functionality:

const neopolitanTest = {
  const obj = {
    topic: topics.commandTopicResponse,
    action: {
      cmd: 'neopolitan', // indicate that this should run using the neopolitan project
      data: 'test' // run its 'test' functionality (open the board, display some words, close the board)
    }
  };
  return obj;
};

But what happens when you need to send a larger amount of data?

const neopolitanUpdate = { // indicate that this should update the state of the Neopolitan operation
  const obj = {
    topic: topics.commandTopicResponse,
    action: {
      cmd: 'neopolitan', // indicate that this should run using the neopolitan project
      data: 'update', // run its 'update' functionality
      updateData: {
        say: 'display a new message', // set the current message on the board
        speed: 'fast', // set the scroll speed to fast
        wrap: False, // indicate that when the message "scrolls off" it doesn't wrap back around
    }
  };
  return obj;
};

That's all well and good and makes sense: we can just add another field to the payload.

But how do we indicate to the web application the types of data that are accepted? I suppose we could build a new topic route possibleUpdateOperationValuesRequest/possibleUpdateOperationValuesResponse that says something along the lines of { say: string, speed: string/float(range), wrap: boolean } and request it when we need to display the update input in the web app. The other option, which I'm leaning towards right now, is a more hardcoded functionality: every possible operation defined in neo has a specific component in dibiasky. This would make it so that every possible value can be input in an easy way for the user and have the correct data type.