Rixfeed Dev Log

Alpha launch blockers:

• ensure summaries are created, there seems to be a bug
• improve real-time chat update speed. fix message poller to do a direct lookup for the newly created nodes. this will require storing the IDs of the created nodes in the event bus. potentially one could debounce subscription updates
• test sign up workflow end to end for a ghost profile
• test signup workflow end to end for an Ask profile. when you sign up, i'll create an Ask profile for the user by default. this user will be their virtual assistant (whose identity they may also assume (by setting their active user ID to the he Ask profile's ID)
• fix interactions that feel "sticky", like menu open, profile select, and potentially others. this means I will also likely have to update the routing design
• entering a direct ID in a Search should always bring that node to the top of the results

Nice to haves:

• update menu bar. i can envision a single row of menu icons at the very bottom of the screen. perhaps with a small chat input inline or over top of it. some of these buttons are actions and some of them are collections. when you tap a collection, it will either 1) pop up another level above with the next set of items or 2) open a larger menu with the icons and a search/filter icon. there should also be a master grid you can filter, very similar to ios's home screen and app search filter. you could build "tool sets" and "tool bars" into homes screens. this UX concept lends itself nicely to the current design for the "tool wizards". that is the statically routed, server side render oriented workflows for complicated user interactions that store their working state on the server. the interaction between wizard steps is a Directed Graph and acts as a state machine. server actions are triggered by accessing the route. for instance, in an image upload scenario, after clicking upload i will be directed first to an uploading landing page that simply displays a spinner. when the upload finishes, the user is redirected to either an error or success route. so, all that said, the route for such a thing is /tools/select-image?w=<workflow-id>&s=uploading, for example. or /t/ for short hand. since designing that, i made an unrelated design decision to make two part routes act as information on the active application and the selected ID. different applications and will render different menus and components for that ID. /ask/PatrickMichaelsenBot renders a chat bot interface. /profile/PatrickMichaelsenBot . currently the tools functionality is statically coded and the app ID and ID combination is dynamic. but I don't see why we couldn't represent the tool structure with that same pattern: /tools/upload-image. we could even go so far as to include the map as the step. i haven't explored what the third route parameter should be. i think for now i will rely on the less committal query params. anyway, the final path could be: /tools/upload-image?map=success&filters=id:<workflow-id> this plays into map and filter syntax i established for the summary features i implemented. map transforms the results of the node. it determines how the component is rendered. if a type is not mappable, the node is rendered as is. but you might want to filter on that node type as well so you don't get intermingled results. if multiple maps are provided, they are applied with precedence determined by their input order. if a filter is for a single node, it may make sense to catch that during the service layer and make the cheapest access cal available. i expect this to be a firestore query, but who knows, algolia instant look ups or filters may be cheaper or faster. ya never know. one thought is with an algolia filter i could get all the necessary data in one call. filter for private profile, active people, upload-image, and workflow ID all at the same time. doing this however does require figuring out which exactly are which only after you receive the results. doing so shouldn't be terrible difficult. this is getting dangerously close to hydration, which i dare not do. well use utility methods to help with nodes that reference each other. i dare not mess with hydration. we can then, later on, experiment with sending data updates as transactions
• make profile icon return to profiles page

tags: rixfeed dev log

---

for the text above, please note any concepts ideas words or phrases that would be good to add to a glossary or to have a link to reference more information on that subject