Replies: 1 comment 3 replies
-
|
Really nice questions, it provides a lot of context around the ways of working.
|
Beta Was this translation helpful? Give feedback.
-
|
Really nice questions, it provides a lot of context around the ways of working.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Design System
1. Are you using a UI library or building from scratch? Shadcn?
We are building up our own UI library in a project called kubetail-ui that consists of a Tailwind plugin to establish a common set of color and style defaults, and some basic components (e.g. button, dropdown). Currently the library consists of components pulled in from a few libraries including shadcn but as time goes on we want to switch to shadcn wherever possible.
Project Goals and Requirements
1. What are the project goals? Scope?
The goal of the project is to identify some basic usability improvements to the Kubetail dashboard's home page and logging console (e.g. colors, typography, spacing) and in the process learn about Kubetail users and the product as a whole.
2. Timeline?
1-2 weeks to identify usability improvements then another 1-2 weeks of answering engineer questions at implementation time.
3. We are establishing a design system?
Long term we want a complete design system but for the purpose of this project we should only establish a minimial design system that will get us a few usability wins in the short term. Ideally this minimal design system will be the basis for a more complete system in the future.
4. Are we designing for light and dark mode?
Yes, we are designing for both light and dark mode. In fact, most developers seem to prefer dark mode but this is annecdotal.
5. Are we designing only for desktop?
Yes, we are exclusively designing for the desktop. Although we may want to design for mobile in the future, currently we are only focused on desktop.
Collaboration w/ developer
1. What should the dev/designer collaboration workflow look like?
While a project is in the design phase, most collaboration will take place casually in Discord, Figma or GitHub Discussions. Interested developers should feel free to poke around designs and ask questions, and designers should feel free to pull in developers to ask them for their opinions. Also both designers and developers are encouraged to ask our users (many of whom are in our Discord) for their opinions.
When a design is ready for implementation, we will prepare a "Technical Spec" using the template in GitHub Discussions. The spec will contain a description of the change being proposed and any mockups, if appropriate. The process of writing the spec is an opportunity to bring everyone together on the design and implementation side and hash out most of project details at a technical level. Once the spec is ready, we will turn it into an a GitHub Issue where it will be picked up for implementation. Depending on the complexity of the project, the implementer might have some follow-up questions and we might need to revisit some aspect of the design or the technical spec.
Outside of specific projects, there are always small design questions that come up and both devs and designers are encouraged to talk to each other and ask for help in Discord, with a preference for communication over open channels so as many people can stay in the loop as possible.
2. How are we prioritizing which issues to tackle on first?
At the moment, intuition. We use the product ourselves so intuition can take us pretty far but in the future we would like to conduct more formal user interviews to identify priorities.
Collaboration w/ designer
1. Establishing working and collaboration norms?
We have a "Contributor Resources" page on our GitHub org homepage: https://github.com/kubetail-org/ where we have been putting all of our contributor-related documents. We should identify any missing documents or other ways to establish working and collaboration norms. One thing to keep in mind is that every contributor is a volunteer so we have to be cognizant of their other obligations.
Problem Space
1. Who are the users? Developers using Kubernetes?
Our users are
2. What challenges/paint points is Kubetail solving for users?
At the moment, Kubetail makes it really easy for users to view the logs for multi-container workloads. A workload in Kubernetes consists of many instances of the same application (running inside a "container", grouped together as a "pod") running in a cluster of servers ("nodes"). Individual instances of the application come into and out of existence so following the logs for an entire workload can be cumbersome. Kubetail makes this easy by letting the user view logs at the level of the workload instead of the individual instances of the applications.
3. What does success look like for the user?
When the user is performing monitoring, success means they feel confidence that the apps in their cluster are running smoothly without problems. When the user is performing debugging, success means they were able to identify the problem quickly or at the very least were able to identify the time slice where the problem occurred quickly and download the logs for deeper analysis.
4. Where does Kubetail fit in a developers journey? (I want to understand the user journey)
Since the only dependency for Kubetail is Kubernetes itself, a user can start using Kubetail inside their development environment to view the logs for their local cluster. With Kubetail running on the desktop, you can easily switch between clusters so a user can then switch between their local cluster and a remote cluster by using the cluster picker in the UI. By default Kubetail only obtains cluster data from the Kubernetes API which is very limited. If a user wants more advanced functionality such as log file sizes, last even timestamps and remote search/grep they can install the "Kubetail API" to upgrade their experience.
5. Who are Kubetails’s competitors? Datadog? Newrelic?
There are many companies and projects building observability tools including Datadog, Newrelic, Grafana, Victoria Metrics, Honeycomb, Mezmo and SigNoz. Currently, the most popular tools all require users to use a hosted or self-managed service to store/host/serve their logs and metrics. The approach we're taking is to be extremely light-weight and zero-cost so users can extract as much value from their clusters as possible without spending any extra money or much compute resources.
6. What screens do we currently have?
Currently we only have a "Dashboard" product with a home page for displaying workloads and a logging console for displaying logs themselves. When the dashboard is run in
auth-mode: tokenthere's also a login page where a user can input a token.Beta Was this translation helpful? Give feedback.
All reactions