Most of design is done still with a embarrassing amount of data. Having released software for decades, we still don't know exactly what module is the most used, what workflows the customers are following, where do customers fail. It is all guesses and opinions.

The idea of this project is to research:

  • What options exists to collect UX/telemetry data from:
    • Web applications
    • command line applications
    • Custom desktop applications
  • Are there any standards on the data format, server implementation, etc?
  • Collecting data is a sensitive topic, even more in enterprise environment. How can the data be anonymized, checked and voluntarily transmitted in a transparent and hassle-free way?
  • How can the data be published for public interest and consumption? eg. open-source communities contributing to these projects.
  • Apart of UX, what other data would be interesting to collect?
    • Instrumentation data for performance improvements
    • Crash data for stability improvements.

Looking for hackers with the skills:

ux telemetry data monitoring

This project is part of:

Hack Week 16

Activity

  • about 8 years ago: mvidner liked this project.
  • about 8 years ago: okurz liked this project.
  • about 8 years ago: jiriwiesner liked this project.
  • about 8 years ago: mkoutny liked this project.
  • about 8 years ago: dmacvicar added keyword "ux" to this project.
  • about 8 years ago: dmacvicar added keyword "telemetry" to this project.
  • about 8 years ago: dmacvicar added keyword "data" to this project.
  • about 8 years ago: dmacvicar added keyword "monitoring" to this project.
  • about 8 years ago: dmacvicar originated this project.

  • Comments

    • dakechi
      about 8 years ago by dakechi | Reply

      Maybe this open source project from Intel could give some insights and ideas: http://snap-telemetry.io/

    Similar Projects

    mgr-ansible-ssh - Intelligent, Lightweight CLI for Distributed Remote Execution by deve5h

    Description

    By the end of Hack Week, the target will be to deliver a minimal functional version 1 (MVP) of a custom command-line tool named mgr-ansible-ssh (a unified wrapper for BOTH ad-hoc shell & playbooks) that allows operators to:

    1. Execute arbitrary shell commands on thousand of remote machines simultaneously using Ansible Runner with artifacts saved locally.
    2. Pass runtime options such as inventory file, remote command string/ playbook execution, parallel forks, limits, dry-run mode, or no-std-ansible-output.
    3. Leverage existing SSH trust relationships without additional setup.
    4. Provide a clean, intuitive CLI interface with --help for ease of use. It should provide consistent UX & CI-friendly interface.
    5. Establish a foundation that can later be extended with advanced features such as logging, grouping, interactive shell mode, safe-command checks, and parallel execution tuning.

    The MVP should enable day-to-day operations to efficiently target thousands of machines with a single, consistent interface.

    Goals

    Primary Goals (MVP):

    Build a functional CLI tool (mgr-ansible-ssh) capable of executing shell commands on multiple remote hosts using Ansible Runner. Test the tool across a large distributed environment (1000+ machines) to validate its performance and reliability.

    Looking forward to significantly reducing the zypper deployment time across all 351 RMT VM servers in our MLM cluster by eliminating the dependency on the taskomatic service, bringing execution down to a fraction of the current duration. The tool should also support multiple runtime flags, such as:

    mgr-ansible-ssh: Remote command execution wrapper using Ansible Runner
    
    Usage: mgr-ansible-ssh [--help] [--version] [--inventory INVENTORY]
                       [--run RUN] [--playbook PLAYBOOK] [--limit LIMIT]
                       [--forks FORKS] [--dry-run] [--no-ansible-output]
    
    Required Arguments
    --inventory, -i      Path to Ansible inventory file to use
    
    Any One of the Arguments Is Required
    --run, -r            Execute the specified shell command on target hosts
    --playbook, -p       Execute the specified Ansible playbook on target hosts
    
    Optional Arguments
    --help, -h           Show the help message and exit
    --version, -v        Show the version and exit
    --limit, -l          Limit execution to specific hosts or groups
    --forks, -f          Number of parallel Ansible forks
    --dry-run            Run in Ansible check mode (requires -p or --playbook)
    --no-ansible-output  Suppress Ansible stdout output
    

    Secondary/Stretched Goals (if time permits):

    1. Add pretty output formatting (success/failure summary per host).
    2. Implement basic logging of executed commands and results.
    3. Introduce safety checks for risky commands (shutdown, rm -rf, etc.).
    4. Package the tool so it can be installed with pip or stored internally.

    Resources

    Collaboration is welcome from anyone interested in CLI tooling, automation, or distributed systems. Skills that would be particularly valuable include:

    1. Python especially around CLI dev (argparse, click, rich)