quote: Original post by Prefect
(Emphasis mine) Please tell me how a system that''s radically different from what the user is used to can be easy to learn...
By eliminating unnecessary tasks, like saving. By focusing on what the user is doing or going to do, rather than what the designer was trying to do (docu-centric applications, SDI, floating toolbars/palettes). By reorganizing internal models while applying the same or similar external models such that new functionality is available (example: Transform the current hierarchical filesystem internally to one big flat directory, then allow the user create directories byt symlink files into place rather than actually copying/moving. Directories now become metadata that users can filter through when searching or performing batch operations, and since files "exist" in directories via symlink - directories essentially become file subject associations rather than locations - they can have multiple metadata entries).
quote: ...and how it gets away without invalidating most (if not all) of their existing experience.
Familiar elements from the GUI paradigm that are worth keeping (and in some cases, worth expanding on) include icons, buttons, 3d shading, drag-and-drop (but consistent; Windows left- and right-mouse button behaviors differ radically), windows, etc.
quote: Apparently you just misunderstood what I said, because your reply isn''t that far from my personal opinion.
quote: The point is that many people are afraid of radical change, even when the final system they would change to is objectively better than what they originally had (and for good reasons like retraining and so on).
Radical internal change. External simplification (it''s just like Windows, but you don''t have to save because the machine will save for you; and you don''t have to worry about moving files around because the machine will track and update all references to them for you; and you don''t have to...) It doesn''t require a whole lot of retraining, but it boosts productivity immensely.
quote: In the end, radical changes are first taken back and then integrated piecewise. That doesn''t mean the change doesn''t occur. But it does reinforce the point that radical change needs to happen slowly, so that it is, in fact, not radical anymore.
Radical change doesn''t need to happen slowly. Those with vested interests in the existing models and uncertainty with regard to the future model think it does, though, and force it to if they have that power. Win16 to Win32 (Windows 95) was a radical change. Not externally, because so many visual elements were similar or identical, but internally: pre-emptive multitasking meant people didn''t have to think about closing open applications before starting others like they did under DOS/Windows 3.x; it meant that developers didn''t need to release the processor every few cycles to give other applications a shot; it meant fewer crashes and more productivity.
My, how short memories are.
quote: Actually, this reminds me of how Linus Torvalds doesn''t accept huge "radical" kernel patches but demands that those be broken up into smaller patches that still make sense.
Exactly how relevant is Linux as a desktop solution? How viable as a big iron solution? I like Linux, but I know exactly why it''s marginalized - lack of radical change, lack of a killer application. It''s not the kernel that''s at fault, though, and Linus isn''t wrong by requesting stepwise patches. It''s the userland applications that could have the most impact on how users view and perceive the system; it''s the infrastructural components like filesystems that can really boost user productivity.
quote: Sure, the IDE can provide that information. Some people might prefer to use the CLI, however. (not to mention automated build-tools running as some background process). They should be able to use the same project files for compilation, so a fallback is necessary.
The IDE and the CLI could use a common repository that defines what tools to use.
