Decisions
From Woofgui
Contents |
Info about decisions
HowTo discuss our decisions:
- description
- priority (high, medium, low; becomes useful when we have a lot of ideas for features which are not all equally necessary for woofgui to run properly or for our project to get started with the right tools)
- present handling
- suggestions / alternatives
- grounds
- decision (keep this short, like: name votes for option.)
General
Name
Description: Clearly, we'll have to come up with a fancy name for our app.
Priority: high
Present handling: It started as woof (Web Offer One File); on gtk-apps it was woof_ui; now it is woof_gui but on launchpad it is woofgui
Options:
- Adopting a new name reflecting the programs origin, but being fancy enough to stand on its own:
- Wui (Woof User Interface)
- Woofer (Web-Offer-One-File-ER)
- Woomf (Web Offer One (or) Many File(s))...
- Woosh (woof sharing)
- Woofish (woof file sharing; sender uses woof, receiver fishes file from world wide web).
- keep ideas coming!
Grounds:
- using 'woof' recognizable: gives most credit to the original program.
- Let's find a simple, sexy name that might be an acronym, but does not require people to understand it - Just like Woof does!
- pro "Woofer": great because it reflects the evolution of "woof" while still clarifying that it's something newer + more awesome!
- pro Woosh: only 400.000 hits on google
- contra Woosh: less associated with woof
- contra Woofer: 6.500.000 hits, mainly associated with audio; it is up to us then to redefine the word.
- pro woofish: it is not woof, but still woof-ish, both sender and receiver action in name (woof and fish).
- pro woofit: no audio-association, 10.000 google-hits (we can beat that!), clear, woof reminded, inviting
Decision:
- Woofer: Tobias, Martin (2nd)
- Woomf: Chris
- Woosh: Tobias
- Woofish:
- WoofIt: Martin (1st)
Naming-Scheme for fully-fledged releases
Description: Every cool piece of software has a funny naming-scheme for the real releases! We need one, too!
Priority: low
Options:
- Using funny names from "The Big Bang Theory". See Naming-Schemes for more details on this!
- Dogs: using dog names / different dog-breeds (Dalmatian, Mastiff, Poodle ... see this A-Z-list) for this (associating woof with barking and file transferring with dogs getting the newspapers)(and we'll have to release a were-woof edition if we adopt this)
Decision:
- Big Bang Theory: Tobias, Chris
- Dog breeds: Tobias
- at least favoring a naming scheme, lol: Martin
Language-support
Description: We can add language-support, question is at what moment?
Priority: low (for taking decision, that is; the feature is nice enough)
Present handling: English
Options:
- "Option: Before" -> If it is easy: add language-support right before a release. We need to get fixed on the phrases that appear in the GUI and need to be translated, though!
- "Option: After" -> add language-support after initial release(s), when we settled all message-texts and have some users.
Decision:
- Before: Tobias, Chris
- After:
Usability
Modify OR enhance the original woof-console-concept?
Description: Woof was a console-script. We began our work on the GUI by replacing lines of code that were meant for console-output with lines calling upon GUI-elements in Gnome/KDE. What I propose is that we begin anew: We make a check for GTK/QT and then do NOT replace the original lines of woof-code, but provide additional lines of code for GTK/QT-users for GUI-output. This way, our tool will still be fully functional from the command-prompt - Which is really cool!
Present handling: Replace console-output lines with GUI-commands
Priority: high
Grounds:
- Enabling our software to be just as usable from the console as it will be from the GUI makes it far more usable for people outside the 'normal' Gnome/KDE spectrum: Think of OLPC-users with 'Sugar' as desktop, netbook-users with e.g. Linpus-Linux or people on Linux-based mobile devices with Moblin-Linux and the like... Plus: It will get good karma-points from console-geeks!
Decision:
- Keep console-functionality: Tobias, Chris
- Ignore console-functionality:
Gui-application or filemanager-script?
Description: Do we want an independant gui-app or are we happy with one python-script and a filemanager-script?
Priority: high
Present handling: nautilus-/konqueror-script.
Options:
- only simple nautilus-script / konqueror-script which refers to woofgui
- gui-app with window to set file and variables. This would result in two possible nautilusscripts: one to run woofgui directly (like now, but without option to set variables) and one to run file with guiapp.
- The gui-app can also be launched like any other normal program from the menu. So no filemanager needs to be open.
- Another option: Integrated filemanager-script (like now), but with a component in the tray-area of the desktop: libnotify will report when a file is accessed, the user can look up the IPs again etc.
- question: does this enable interacting, like cancelling or grabbing urls to clipboard? Will that be supported in jaunty? Do we need interacting?
- Like this?: gui-app (pro's: can be launched without file-manager open; files can be drag 'n dropped on launcher in dock / panel / desktop), with button to advanced-mode for changing variables which are already preset to default; with grab-button to copy urls; pressing ok moves window to systray, notifications from there, no further interaction unless user wants urls: clicking icon will give notification bubble with urls.
Grounds:
- pro naut/konqu-script: less clicking;
- pro naut/konqu-script: no need to select files afterwards; but: we can as easy make n-script for gui-app
- pro naut/konqu-script: easier to select dirs (which woof can tar).
- contra naut/konqu-script: woofgui not usable without nautilus/konqueror, whereas woof is.
- contra naut/konqu-script: no option to set variables
- Isn't this a pro-argument? => IF we do our jobs right, the user should not need to set many variables! I even adise against it: The user should just click on a file and have it shared without entering anything!
- Not if a file, especially a larger one, needs to be woofed to more than one receiver. What is woof's behavior when a file is still uploading and the script is run again? Does it use an other port, does it allow another download, does it give an error?
- pro gui-app: no need to control evertything from the python-file we are using now. We can use one window which can stay while woof is activated and runs. Easy opion to cancel woof after it was activated (e.g. when connecting ip is not trusted, or sharing became unnecessary.
Decision:
URL-providing
Description: How does woofgui provide user with urls; how can user copy-paste?
Present handling: copy to clipboard when 'ok' is pressed.
Priority: high
Options:
- use clipboard
- grab-button which stores url in clipboard
- (very advanced) offer buttons which open new mail with urls in message or which open chatmessage to selected buddy (like gnome-do plugin). These should be alternatives to the 'ok' button, because woof has to run in order to generate urls.
- systray-icon with notification-bubble with urls, can be repeated by clicking
- embedded shell-output
Grounds:
- pro clipboard: less clicking, no extra window
- pro clipboard: user selecting and copying with his mouse can go wrong, e.g. missing first or last characters. Also typing from bubble can cause mistakes.
- contra clipboard: people may not like messing with their clipboard
Decision
- button with option copy-to-clipboard on main window and also systray-icon with bubble: Martin
Message what ip-adress connected
Description: How do we handle this?
Priority: low
Present handling: none
Options:
- no message;
- extra popup windows;
- (very advanced) maybe it is possible to create window which shows shell output (like ubuntu update-manager window).
- notifications-bubble
Grounds:
- Not very important because connecting ip-adres will most of the times be unknown, unless outside lan when inside was expected.
- pro notif-bubble: no annoying popup windows that must be clicked away, and user is notified nonetheless.
Decision:
- bubble with short time-out: Martin
Post-launch cancelling
Description: Offering a cancel-option after woofgui is launched.
Priority: medium
Present handling; none
Options;
- Extra window with message "[ip-adress] connected" and 'cancel'-option.
- Notification-bubble with 'cancel´ button (we'll need a distro-independant method then, since jaunty won't support buttons; does pynotify do the trick?)
- Gui-app minimizes to traybar; notification-bubble with connecting ip-adress; cancel-button on gui-app
- In gui-app embedded terminal-output; cancel-button.
Grounds:
- Pro: We should offer cancel-option also after woof has started, e.g. when connecting ip-adress is not the intended receiver and / or not trusted.
- Contra: Problem: this would require an extra window, since the new notification handling in Jaunty deliberately does not support actions like buttons. We could maybe use an alert box (https://wiki.edubuntu.org/NotificationDesignGuidelines).
- contra embedded terminal-output: will not be read when minimized
Programming
Python-update
Description: updating python-script; woof has been written some time ago now.
Priority: medium (building upon buggy code is unwise)
Options:
- We should check what has changed in python since woof was written; what commands are deprecated etc. We could get an advanced Python god/dess to have a quick flyover through the existing code & make remarks as to what needs to be changed - We then document it, research it & fix it one step at a time.
- Also, Python 3.0 has been released which changes a lot of things. Right now, Python 2.6 ist still widespread, but 3.0 will become the standard sooner or later. We will have to update the code for this someday!
Decision:
Encryption
Description: A killer-feature for our software would be if the HTTP-connection could be SSL-encrypted. There's a python-library out there doing the heavy-lifting: [1]. What we need to find out is how much trouble it is for the user to get a SSL-certificate to use. Can we just generate one on the fly, let it be unsigned by official organizations and still get good encryption without hassle?
Priority: low
Options:
- Pro SSL
- Contra SSL
