The current Jangouts UI is limiting us when thinking about adding new features. Some examples:
- This (using the whole thumbnail to pin a participant) was implemented, but the result is far from optimal (I have not even deployed it in production).
- The underlying part of this (participant name change) were also implemented, but we were not able to find a way to make it fit in the current UI.
- If somebody decides to implement this (per-user volume), they will have the same problem.
- I also have in mind a "local mute" feature, but once again I wouldn't know where to place that button.
Moreover, there are some usability problems we keep hitting all the time:
- The button to mute yourself can move if somebody else than you enters the room.
- The name of the room is not displayed.
Last but not least, the current UI kind of works in mobile devices, but it's not 100% mobile friendly (buttons are too small and it relies too much in hover buttons).
I already have other projects for this Hackweek, so I'm not sure how much time I will have to work on this. But if some javascript or UX expert wants to jump in, I will help as much as possible.
Final result
Cynthia already did some visual modifications (available only in her fork for the time being). She is also working in some mock-ups more oriented to functionality and UX. Stay tuned.
Ancor did progresses in the Angular2 porting and improved the unit tests there. He also updated the janus-gateway packages in OBS and renewed the Let's Encrypt's certificate for jangouts.tk. Last but not least, he debugged some connection problems with Firefox 38.4.0 (included in non-updated SLED12-SP1). The problem should be fixed now.
Looking for hackers with the skills:
This project is part of:
Hack Week 14
Activity
Comments
-
over 9 years ago by ancorgs | Reply
As a first step, I'm taking a closer look to our experimental Angular2 version (GSoC) since I want to develop the new UI on top of that.
I'm finding it to be quite daunting for a beginner (a lot of warnings due to the WIP, some lack of documentation...). I'll try to fix that first.
-
over 9 years ago by ancorgs | Reply
Still working in improving the Angular2 branch, specially improving the tests and the developer's experience. Learning a lot about typescript and jasmine in the process.
Cynthia is working in some mock ups for the interface. Most likely we will not be able to implement them as part of this Hack Week, but at least we will end up in a good position to do it in the future (with test cases for the existing code, at least).
-
over 9 years ago by ancorgs | Reply
Cynthia is already modifying the look&feel (she even created a motto!). Everything looking nicer so far. We were also discussing some stuff more related to the user experience than to the look&feel. She is working on some mock-ups on how to fix it.
Meantime, I'm using this project as an excuse to do jangouts-related pending stuff, like learning Angular2 and typescript. Helping our GSoC student to create meaningful and DRY unit tests, trying to reproduce some problems reported by a SLED12 user with an old Firefox, updating the janus package and so on.
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:
- Execute arbitrary shell commands on thousand of remote machines simultaneously using Ansible Runner with artifacts saved locally.
- Pass runtime options such as inventory file, remote command string/ playbook execution, parallel forks, limits, dry-run mode, or no-std-ansible-output.
- Leverage existing SSH trust relationships without additional setup.
- Provide a clean, intuitive CLI interface with --help for ease of use. It should provide consistent UX & CI-friendly interface.
- 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):
- Add pretty output formatting (success/failure summary per host).
- Implement basic logging of executed commands and results.
- Introduce safety checks for risky commands (shutdown, rm -rf, etc.).
- 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:
- Python especially around CLI dev (argparse, click, rich)
Kudos aka openSUSE Recognition Platform by lkocman
Description
Relevant blog post at news-o-o
I started the Kudos application shortly after Leap 16.0 to create a simple, friendly way to recognize people for their work and contributions to openSUSE. There’s so much more to our community than just submitting requests in OBS or gitea we have translations (not only in Weblate), wiki edits, forum and social media moderation, infrastructure maintenance, booth participation, talks, manual testing, openQA test suites, and more!
Goals
Kudos under github.com/openSUSE/kudos with build previews aka netlify
Have a kudos.opensuse.org instance running in production
Build an easy-to-contribute recognition platform for the openSUSE communit a place where everyone can send and receive appreciation for their work, across all areas of contribution.
In the future, we could even explore reward options such as vouchers for t-shirts or other community swag, small tokens of appreciation to make recognition more tangible.
Resources
(Do not create new badge requests during hackweek, unless you'll make the badge during hackweek)
- Source code: openSUSE/kudos
- Badges: openSUSE/kudos-badges
- Issue tracker: kudos/issues