Wikis as communication method between users and developers

Wikis can be excellent communication portals.

A user interface should be discoverable enough that the user does not have to read documentation for basic operations. Online help, consistent functionality, tooltips, and descriptive and familiar icons can make an interface discoverable.  Users will need to consult documentation for obscure or features that are being tested.  A wiki with detailed use instructions is actually a specification for developers.  The details on how features are implemented are actually for the users and administrators.

Wikis allow for multiple views of the same data, very much like the tags in gmail.  It is possible to categorize and group content into small articles, and link to all related topic.

A large wiki page is harder to translate than a single topic page. Links to all related topics can bring a user from merely using a product, to customizing it, to contributing to it's design, to actually implementing the new features.

It is very important to keep the user and developer pools overlapping. This will save time, allow for easier translation and organization of documentation, and provide ways for new features to be documented before they are implemented.

KDE needs to have a unified wiki again. Simply merge all three of their wikis and start breaking them up into smaller pages. This is a big deal, and I think KDE has had some really inefficient and cumbersome design decisions that could have been avoided by architecting it in a unified environment.

Gibberish Detection, and the "catcha" lesser captcha lock

** The catcha**
A catcha is a very simple captcha, that is quick to solve and is intended to determine that the action was intentional, but could be exploited by automatic means so is not suitable for security.

** back story**
When I was a kid, my dad told me how he started checking software for bugs... just hold down a key.  Half the time the programs would crash.

All of the Macintoshes at my high school (os 7?) would be unusable for hours if you just held down a key for a couple minutes.

A cat on the keyboard will hold down keys, and will still cause modern programs to misbehave.

**Design thoughts and details**

I propose having a "spell checker" for general user interaction.
This would include general mouse patterns, and detection of out of normal shortcut keys.

control-alt-prntsrcn  REISUB   (Raising elephants is so utterly boring)   would still work of course... that key combo is so hard for a cat to press accidentally, that I'm pretty sure that it won't happen accidentally..  (unless it is the wrong keyboard--going to the wrong computer!)

Little kids will also start typing gibberish when sitting down at a computer.  If a key is held down, or common application use is not observed,  a simple "catcha" lock could be presented.


Control mechanisms, and issues to overcome:
some programs take gibberish like input (vim-- up down right left)
Vim keys would have to be accounted for.
people misspell things...  It should detect word-like writing, and do so over time..
possibly by detecting the number syllables, and variety of syllables.

If a dangerous control is detected in the midst of gibberish like behaivor, a catcha should be presented.


** Security issue**
this program would use a key logger like program, which may cause a serious security issue. Measures should be taken to ensure no other processes can get the data  It should not write data to disk, and clear it's data frequently,  Also, it should not be operational on login screens, and it could turn itself off after regular behavior is established, and turn on after a timer.

** implementation level**
I think this could be a part of the x input system...  it could also be done as a terminal or shell..

Computer User Interface trust.

I was creating a directory structure in Dolphin, so I typed in  bar/bux/baz  in the create folder dialog.  I expected an error, or a path to be created.   Instead, it converted "/" to a look alike, that I cannot simply type in the terminal.    I feel violated.

https://bugs.kde.org/show_bug.cgi?id=299086

Why is this such a violation?
I expect the computer to do what I tell it to do, and check for sanity. If it can't do what I asked it to do, I need it to ask me a question, or at least tell me what it plans to do.

Our computers should not take the names of files in Save-As dialog boxes. I have overwritten a file that took me hours to make because some ass hat decided to make a mouse-over take a filename, and the default action for the confirmation dialog box was yes.  (we got that one fixed)

Files on removable media should not be put into trash automatically,   This leaves the drive full, with no obvious way to clear it.  Instead, something less than trash would be a good solution.
Queue to items to be deleted...  and don't move the files to another folder until the queue is acted upon.  This list should at least use tiemstamps, and the deletion program should check lsof to verify the file is safe to delete.



I understand that training and experience has a lot to do with what people expect computers.  What are some things that we have been trained to do, that are a bit messed up?

mice and trackpads.

Single clicking can be done by accident very easily.  Nothing dangerous should occur by a single click.  Everything should be reversible.    A double click should not perform an action twice.

hyperlinks, toolbar actions, and buttons are for revertible actions.  A SUBMIT FORM FOR A WEBSITE SHOULD NOT BE A SINGLE CLICK

Buttons for hazardous actions should look differently than a safe action . Perhaps a color change should occur on the first click.

A hazardous action could be defined as anything that could cause data loss. 
Running a program, opening a file,  these are all hazardous.

Dangerous actions explicitly cause data loss.
Saving over a file is dangerous,  (are you sure that is the right file?)
running an unauthenticated program is a dangerous action.

Deleting a file is a dangerous action.
(moving a file to trash could be classified as hazardous)
    


Taps frequently occur without the user knowing.

Tap-drags are pure evil.

I like how Microsoft has a default action of copy when dragging files between volumes.   I like how they move by default when dragging within one volume.

I also like how Dolphin asks me what I want to do.   but I don't like how it gets in my way.

I would like to have an informational dialog box show up, saying "move to" or "copy to" when I approach my target. 

Holding down both buttons on a drag should cancel the drag.
Right click dragging should bring up the questionbox. (on drop)

(Yet another reason why Macintosh's are horrible)

internal representation of actions in the desktop and shell

When looking through the source code for KDE, I saw actions like on click.

I was looking for a way to solve the bug where the system settings panel uses the same settings as files.    The system settings page is basically a web page, where single click is expected, but some idiot decided to punish people for setting double click as their preferred interaction method.

This got me thinking about how to represent interactions with the user, so that programmers are not confused by click.

This is also relevant for touch screens.


I would organize actions by how explicit/deliberate of a request they require.,  so that they could be adjusted by a system setting, and still

onpassiveInquery --    mouseover
oninquery -- righclick
onprobe -- single click
ondoacton --doubleclick
onexplicit action -- double click plus dialog or other interactive confirmation
ondangerousexplicit action -- require a captcha to be typed in
onsystempermission -- requrie sudo level...  (this may still be separete.


This would allow us to design interfaces for multiple types of interaction, and swap the code for the interaction based on what type of device it is.

Solution for yanking a liveusb drive out

 Regarding Live Distros,  Knoppix has a "to ram" option, where it copies the compressed file system to ram, and then the media can be removed.

I can't use that on my system because I only have 1gb ram.

Knoppix can create a swap file on a windows volume. (and use another system's swap partition)  I don't want my users to mess up their windows disks.  Yes, they can mount them and write to them, but I don't want accidents.


A solution would be to split the compressed filesystem into two parts.  one that gets loaded into ram, and another that stays on the liveusb drive.

/bin
/root
/etc
(maybe a few of the core applications, like xwindows, and some sort of alert programs, and maybe cheat with a web browser in there so it loads quickly)

and then another with all the rest.

If the system volume gets yanked, a program should pause everything... like a pause for hibernation.  Hopefully the programs will be able to deal with a minor glitch.  If they can't it's a bug.


Then a nice big alert should show,   REINSERT USB DRIVE TO BEGIN DATA RECONSTRUCTION, SYSTEM SUSPENDED, DATA IS LIKELY CORRUPTED

The Sanity Shell

As part of the Cat Proof Computing Initiative,  I want to have a shell that is extra rhobust, and will keep users safe from bad things, and becoming interactive at a certain point. I'm a bit pumped up from Linuxfest.

• I want to be safe from having files names -rf.
• I want parenthesis matching
• I want abnormal filename detection.
• colorized edit line. (all the text editors do it) 
• interaction with the terminal so that an output that would display encoded characters does not leave the other applications that follow it in a strange character mode.

some of this danger could be mitigated with aliases.
some of this might require simulation.

*For the simulation*
I can conceive of situations where the action could not be simulated... say with self modifying code, or detection of the conditions like being on a different filesystem.

white listing actions could be interesting...  but this isn't an easy problem to solve.


 I just had a thought  that I could use mount --bind to make a read only copy of my file system.  I then could make a folder differences apparent by having unionfs overlay,  then perform the actions and  confirm that what happened was ok, then apply those changes.


 I think this is a bit like having a transaction based shell... well we have transaction based filesystems, so that is likely the best way to deal with the idea... and reverting has less overhead.

*For shell and terminal interaction, I have seen terminals tell me what program is running inside it.  It should be able to reset it's characters everytime the shell comes back. by paying attention to it's child processes.