How to Select a Good Laptop. Interface matters!

I'll go over the points that I think are more unique to my laptop selection first, the rest is rather obvious.

Try the physical user interfaces!  Except for gaming, and some content creation, the rest doesn't matter much.

Trackpad:


1.  The trackpad should let your finger move freely over it. If it is textured for style, it may not perform when you are using it.
2. The trackpad should have edges to let you know when you moved your finger out over the way.
3. There should 2 discrete buttons, that are next to eachother, so you can press both at the same time with a single finger.     (pressing both mouse buttons at the same time is a shortcut to cancel your current mousing activity),  pressing both mouse buttons can also be interpreted as an additional action (3rd mouse button).
4. The buttons should not be "integrated" with the trackpad.. if it is all one piece of plastic, then it will be harder to cancel an unwanted cursor movement.

Screen:
5 the screen: should be non-glare MATTE,   NOT GLOSSY.   If you see your reflection in the monitor, this laptop will give you much pain and suffering.

Body:
6: the body: should feel sturdy... it's ok if it looks somewhat cheap, some designers put more time into making the object function..  The body should not flex when you twist it.

****
Switches
7: Hardware switches:
volume key, if you can actually control the volume immediately with a knob, this laptop is great!
Hardware wifi on/off   I don't trust the software only..

8: unadvertised features matter more than some other features:
Virtualization in the cpu.  I only recommend laptops that have virtulization enabled.    This will let you run other operating systems at the same time, which is amazing, and cool.  This is a bit harder to lookup, because they don't advertise this on laptop cpus.



The stores:
***
At Fry's:  I would not buy a single laptop they had out there.  Either some sort of fingerprint reading device is disrupting the functinality of the trackpad, or the buttons are spaced far apart, or the trackpad is textured like sandpaper.
***
At office stores,  they typically have just one or two models with non-glare screens. If the mouse buttons work, this is great.




I order things this way:
use
interfaces
price
size
performance
battery


Screen type by usage:
MATTE

Do everything:
I prefer smaller laptops with high resolution displays. (13in and smaller, with sxga or wsxga  )  (1400x1050 sxga+ is what my 13in  laptop has, and it is great. but I could get away with 1280x800)

I always plan to be near a plug, and buy an extra power adapter.  I typically go for discrete graphics level performance (AMD now has on chip 3d acceleration which is probably good enough)  but I want a discrete video chip and discrete video memory.

Take everywhere:
 My dell mini 9 is just great.. it has a 9 inch screen with 1024x600 resolution. It was cheap, and it is fast... It is enough of a laptop to do anything I need but 3d editing and games  or video editing(which is what I need to do :(

Poor eyesight:
If you have poor eyesight, you might select a 15 in panel with 1280x800

HD Video Editing:
Ideally, I would like to have a WUXGA 1920x1200 display if I am going to be doing anything with HD video.  (this would probably be a 17in laptop)


Interfaces:

I perfer dual pointing device laptops with the touchpoint and the trackpad.

General communication.

So many fields and topics are deeply related.  Computing devices are showing up everywhere, but they are used to solve problems we have always had.

I had a chance to observe a parent and child interact in a way that reminds me of poor user interfaces.

On (many days) that day,  The parent started talking to the child, and the child did not respond. The parent moved on to do something else.  The child did not do the task that was demanded, and the parent became angry.      It was like the parent used UDP to communicate a critical message, and the packet got lost.   The parent should have used something like TCP, where a message delivery confirmation is expected.


This reminds me of unix programs that don't report on success.   Maybe there is a way to provide a sub-channel communication that indicates success.

It could also be possible to remap cp, mv, mkdir, and other common programs to use Kio and kfile (from KDE) to give someone notifications when transfers are done.  A simpler way to do this could be to have these programs log actions, (and use trash folders)

Physical Buttons, trusted shell indication light and display

How many of you are annoyed by administrator password prompts?

I sure could use a non-spoofable* authorization button and console.

*(will need engineering and kernel integration, root cold spoof it anyway)


Here are the basic parts,
an lcd terminal, distinct from the rest of the system, OR, a physical light that indicates that information on my screen is not just some elaborate userspace spoof of an authorization window.

This is not just a light that comes on when a sudo program is activated, it is a light that indicates that the video display is verified to be giving out authenticated information.

This information would include, the filename, and what access the program requests.

A hardware button could authorize things like software updates or installs (from authenticated repositories only)  with just a press.

A(the) hardware button could be used to confirm execution (or opening) of a newly downloaded file.

A(the) hardware button could be used to  authorize system settings changes..

For additional security, the system could be set to not prompt you for your passwords until you press the(another) button

Codes or patterns could be used for some authentication (morse code or a timer, or presses in response to a song or tones)

If there was a small(or any dedicated) display (a text display, ) this information could be presented on that display instead of the general purpose display.


I believe I heard of trusted computer initiatives before, but it sounds like it may be an alliance to own your computer, and not trust the user...  Perhaps some of the hardware could be repurposed for hardware authentication interrupts.



This feature is similar to the reset buttons on our consumer routers, but this one would not reset data, and it could be manifested by a switch with a safety lock, or flip cover.

I imagine this button would not be on the keyboard, or if it is it would be one of those special keys like on one of the late 90's keyboards with buttons for everything.


I would like to make this project work with a Logitech G15 keyboard.
It has a little display, and it has tons of extra buttons...  but ultimately I would like the button to have it's own device, and only let the authentication program  read from it.

(It would otherwise be possible to have a web page spoof your password prompt, we are being conditioned to enter our passwords multiple times on every login and configuration change...  This would be a great way to authenticate routine maintenance, and enforce a more deliberate and communicative authorization process)

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