ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Cheat Sheeter

New Program Idea: Cheat Sheeter

<< < (9/12) > >>

nudone:
yes, an image would be nice to see what you mean (i think i know what you are describing).

CodeTRUCKER:
APIWATW ("A picture is worth a thousand words").

JavaJones:
I don't know exactly what happened here but my guess is this project collapsed under the weight of its own feature creep. When I read the first few posts here I got an immediate (and I must say very attractive) picture of the workings of the app in my head. Just about everything I read afterward went against that, over-complicating (IMO), adding unnecessary (IMO - at least for now) features, etc. It'd be great to have every feature suggested here... *eventually*. But I say start small, get the thing out there, get people putting together "cheat sheets", and then see if it's popular. If so build it from there based on real-world feedback from real users. A lot of the things suggested in this thread just seem to defocus the core, original objective.

So here's my particular vision, take it or leave it.

1. Presentation is separate from content, period. This is the biggest problem I saw in the ideas being proposed - that people would make their own custom sheets, people would have multiple sheets, etc. This seems silly to me. An application only has one set of default shortcut keys! Multiple people making multiple lists is fairly useless. What you want is people having the ability to change the presentation of a list, not the list itself. So you store the list separate from the template and people can just edit simple CSS files (highly structured due to the structured nature of the content) to get fairly dramatically different looks. This is basic "skinning"/templating and would be ideally suited to this app.

2. Shortcut lists are plain text, or close to it. No need to use an HTML editor to create them, that's overkill and fairly senseless IMO. Presentation is separate from content and most people will not care to change presentation (provided the default is good enough and enough alternate styles are available). They will want to change/add content. Making this as easy as possible is paramount. All that is needed is a simple text parsing system with very, very basic rules. For example, 1 line per shortcut, title/function first, key sequence 2nd (with semi-flexible rules for defining them perhaps), and so on. You could even have a veeery simple shortcut list maker with a small virtual keyboard, you press the key sequence you want (either on real keyboard or by pressing it in sequence on the app mini-keyboard) then type a name in the name field at top and hit Add. Repeat, etc. Very simple. Doing it text-only also allows for easy import/export - you could potentially even import existing shortcut lists and parse them. It would also be good to allow simple divisions/grouping of shortcuts, possibly with an optional "priority" assigned - higher priority groups/shortcuts would be listed higher in lists and shown with more priority in minimized view.

3. Make a very simple but nice-looking default CSS theme. I'm seeing grey, rounded keyboard icons with a non-serif, perhaps rounded-letter font, that highlight orange to show example key-presses perhaps. Maximized version shows an on-screen keyboard below and a list of shortcuts above, minimized version is just a list of actions with a small area below to show keypresses on mouseover perhaps.

4. Allow themes to change the size of presentation, but create an immediate small/large (maximized/minimized) division in skins to act as a guide. People can still make smaller "mazimized-style" skins, or make larger "minimized-style" ones, but the general convention will be to create two stiles for every skin. Look at it like Winamp - by default you have the usual theme with full control sizes, song list, visualizer, etc. But if you double-click the titlebar it shrinks to just a titlebar-sized area. This should be done similarly in this shortcut app. A skin designer would create two CSS files of a specific name which would be switched out by a custom button in the app, possibly similar to the double-click titlebar that Winamp has (or a hotkey :D).

Bottom line I think it makes way more sense to start small and grow from there. Add image and video support and all that later, sure. But what people want most in applications - normal people I mean, not hackers and heavy tinkerers - is applications that "just work" and look nice out of the box. Some people (the skinning crowd) want themable, highly customizable apps, and you can serve that market fairly well even with simple CSS theming. Some people do want massive customizability and for the app to do tons of things, but often times you're better off just pointing these people to a different app that does more of what they want.

What you want to create is a simple, easy-to-use, "set it and go" application. You want to look at the existing possible solutions out there and do it better and easier. If someone can already edit HTML they can easily just create web pages that show shortcut keys, make a directory full of them, and use FARR or another system to setup custom shortcuts to them and basically get the same thing being proposed here. The difference is the integration, ease of use, ease of manipulation (even an HTML-savvy person should appreciate not having to create a whole new page from scratch for every shortcut list), and ease of sharing these files that will hopefully lead to a community. Don't get too bogged down in extra features.

I really think a focus on simple text input and separate CSS theming is the way to go. It will surely result in much more lists being created and shared, and ultimately that is what is going to drive the popularity of this kind of app. If everyone has to create their own using HTML - even a little bit - it will be much less popular.

What I am proposing should be do-able within a week I'd think. It's pretty simple, but ultimately pretty useful and flexible. And more features could be added over time, but it would be immediately useful I think.

My 2 cents. :) If you want to talk more about how I envision this working I'd love to chat about it as I really like this core idea, I just think it got a bit lost along the way.

- Oshyan

app103:
I was just thinking how useful it could be if when it docks at the edge of a screen, that it could autohide.  Kind of resemble another taskbar that can reveal itself when you touch the screen edge. (I still have room for 2 more. ;))

Add a button to lock it when you need it to stay on screen...click again to release and go back to hiding.

It can still have tabs...just like the old MS Office toolbar had. And let the user configure each tab with the color of their choice to make things easier to find.

It would be quickly accessable...quicker than clicking a tray icon.

And just like how the windows key will unhide the taskbar, have a hotkey that will unhide it for keyboard freaks (and one to lock/release it)

JavaJones:
App, right along my lines of thinking too. Those things were definitely parts of the mental picture that came up for me.

- Oshyan

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version