Reformatted into a question....
Is drag and drop a good catcha method? I.e. would it be a good way of allowing only humans to submit a form?
Original text:
You can start voting down but i am a
newbie and here is my captcha version!
The captcha will be based on drag and
drop...
a human being could implement drag and
drop. A bot?
Just a thought!
Per my comment, it's already been done, one example here :)
Drag and drop what? The thing here is not the behavior. A computer can drag and drop programmatically. The issue here is things computers cannot do, or do well. For instance, recent ideas have suggested orienting images right-side up. Like a dog upside down needing to be flipped vertically, or a stop sign needing to be oriented 45 degrees clock-wise. More complicated images would be children hanging upside down on monkey-bars, etc.
Drag-and-drop won't cut it alone. What will you be dragging, and where will you be dropping it ;)
Another issue to address is how a drag and drop system would work if the user has JavaScript disabled. (You'd need to fallback to something and that something would also need to be hard to fake.)
Then again, HTML5 might resolve this issue as long as you don't need mainstream browser support any time this century.
Any javascript-based CAPTCHA will do (no need to do fancy stuff like drag and drop). The only problem is accessibility and support for browsers without decent javascript (hello IE Mobile?)
Is drag and drop a good catcha method? I.e. would it be a good way of allowing only humans to submit a form?
This is nice idea in correct direction.
One should prevent passing captcha to 3d party human solvers sweatshops (which do not directly interact with web-boards being cracked)
But the mentioned
http://www.webdesignbeach.com/beachbar/ajax-fancy-captcha-jquery-plugin
is 100% passable by bots in 5 guessing, while bots have 15-20 before being locked.
The spambot devs I asked about it just called it "a masqueraded trap".
I am making survey of spam and anti-spam techniques and would recommend to look into KeyCAPTCHA plugin.
See my another answer on it for more details.
Update:
I deleted my motivation because it seems to distract readers. This is not about "why don't you make your window smaller". See the screenshots and you will see obstructed text because of fixed width. See my reference to "em/ex" notation in CSS. I would like to have a real discussion here. Thank you.
Now I would like to ask real experts on this topic -- I'm not a web designer -- why fixed width layout are still that popular and if there are really good reasons for it. (you are welcome to point out reasons against it as well.)
Is it too hard to design your layout relatively (from start on)? It seems some people even forgot how to do it.
Do you have real reasons like readability and just don't know how to deal with it correctly? Here I'm referring to pieces of wisdom, like it's harder to read longer lines (that's why newspapers use columns) -- but then, width should be given using em and ex.
Are you forced by some old guidelines? In the dark old age of HTML, people did a lot of things wrong; now everybody finally uses CSS, but perhaps this one just sticked.
Or are you like me, wondering why everybody is doing it "wrong"?
To illustrate the issue, I want to give screenshots of negative examples first:
StackOverflow (here I can't even see what would make it any hard to fix it)
Filmstarts (a german website which renders itself unreadable-if I don't take a reading-glass with me)
And here is a positive example. It looks like a typical fixed with site (even with transparent borders), but it is not:
Website on Wiki software -- associated Forums
What do you think?
Update: Related questions: this one and that one.
And here, as expected, comes the usual canard: “long lines are too hard to read”.
[Citation needed], folks.
See http://webusability.com/article_line_length_12_2002.htm for a summary of actual research in this area. A number of these, plus http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp, find that although users express a preference for moderate line lengths, reading speeds do not sharply drop off with ‘long’ lines; in fact many show increased speeds with the longer settings.
As long as it's not ridiculously long, and taking care to use a decent amount of leading, long lines are not generally a real issue at today's typical browser widths and default font sizes. (If you're one of those designers that loves to use teeny-tiny type for everything, it could be an issue, but then you're already making it impossible to read with the flyspeck text. Stop it!)
So as it's only an option of user preference that prefers medium-short lines, let us users decide how much screen space we want to give the web site to get our work done. We're the ones best-equipped to know. If you decide you know definitively best you're likely to waste space, or, if you guessed too long, make us scroll back and forth sideways to read the text — and that really is a readability nightmare.
If you want to protect us from ourselves, you can compromise by specifying a min-width and max-width in ‘em’ units so that the page is responsive to liquid layout, but doesn't get stretched to extremes.
But otherwise, the best reason to design fixed-width is indeed that it is easier, especially for someone with a fixed-2D-grid view of the world and static visual-design tools like Photoshop.
It's already a pain to make a website that renders correctly across all popular browsers; if you also want it to render correctly at all text sizes, it's quite a lot of work. A lot of web developers design their sites for the default font size and try to support fonts that are either a little bit larger or a little bit smaller. (You might be interested in this dated but relevant piece from Jakob Nielsen.)
As for fixed-width sites, it's hard to say. Personally, I suspect that a lot of web designers just like to feel like they have a lot of control over their look and feel, and think the site looks "ugly" when you stretch it too far, so they don't let you do it. Probably not wise, but there you go.
Now I would like to ask real experts
on this topic -- I'm not a web
designer -- why fixed width layout are
still that popular and if there are
really good reasons for it.
Ah, both subjective and argumentative. I'm sure my argument won't convince you, but here's one really good reason, IMHO:
Presentation.
Just like a movie, the director has an experience in mind for the viewer. They frame the movie just so. They move the action at a given pace for the emotion they are trying to invoke in the viewer. Even though DVDs have had the "angle" feature since inception, few movies have ever given viewers the opportunity to watch the film from a different point of view, and if they have that viewpoint was still under the control of the director.
Now, any old sap can throw up a website, and for the most part they aren't interested in anything more than the content.
But real designers fully understand that the design must be understood as a whole. A wide layout has a very different impact on people than a multicolumn or thin layout. Reader eyes move in a certain pattern, and the text is intended to pull the reader along a path.
Those who claim that every layout should have certain features are shortsighted. There are no universally true 'rules', and trying to make an expanding layout a rule is shortsighted at best, and arrogant at worst.
-Adam
Here are my $0.02 and they are worth exactly what you paid for them (and if that's not a perfect example of the current economic situation... :-))
The layout of a website should be dictated by the overall user experience. This is in part determined by the accessibility, in part by the design, in part by the functionality:
Accessibility - as several people pointed out, letting the website use the full width of the browser without any control can result in quite a long lines that make it hard to read[1]. Making the text automatically layout in multiple columns is a potential answer to this problem, but it's really hard to achieve with CSS (that's gotta be the worst tool for doing layout humanity ever devised, but that's a separate topic) and is fraught with other issues as well.
I should note that you do have a point - most websites with fixed width do suck on high-DPI because they don't take into account the changed font size. However, that's not an inherent problem of the fixed width design; I've seen it with fluid designs as well.
[1] No, I don't have a citation. I, however, have tried reading on full-screen on my 24" 1920x1200 96dpi [2] and gotta tell you - after 15 minutes my neck is cramping from the constant turning of my head.
[2] The typical user still runs 1024x768 or 1280x1024 (based on instrumentation from the product I work on, with about little bit less than 10mln installs for the latest version). So yeah, I am not the typical user.
Design - most modern designs are very rich on graphical and video elements. Most graphical elements do not scale well with the document reflow and video does not scale at all. (I would again blame this on CSS - it's support for dynamic resizing of images is lacking some basic operations and there is aboslutely no support for building and control of the visual tree. But I digress again :-)) As such, disegners opt in for the easier approach.
Functionality - fluid layout is really good for dealing with big text chunks like documents. However, quite a few modern websites are in effect applications, not documents. They have multiple elements and controls and increasing the area on which these elements are scatered makes it harder for the user to keep all of them in focus.
Couple examples:
two control groups that are aligned at the left and the right end will be too far away from each other in full-screen width. Note: that can be alleviated by choosing to always keep all the controls grouped together, like most desktop applications do (almost all desktop apps keep all toolbars left-aligned).
a picture/video and associated text below it. On full screen there are two possible approaches for fluid layout:
a) scale the picture to the full width, at which point the text is visually lost
b) leave the picture the same width, but let the text flow the full width, at which point the picture is visually lost.
I guess my point is that the fluid layout is not the Holy Grail of all layouts and there are scenarios where it's not applicable. The designer and the developer of the webapp should choose the appropriate layout and implement it so that it meets the needs of the target users, delivers the best experience of the product functionality and adapts to the user environment.
I suspect that most web developers go for fixed width because it's by far easier to develop such a site (in addition, many Content Management Systems only offer a fixed-width layout).
Getting a dynamic layout to work well & correctly in different browsers is more tricky - but it is definity doable (I'm just recently working on that issue ;-).
And I do agree with you - I want web pages that dynamically adjust their contents to the browser size that I as the 'customer' like to work with (whether that's small or large). I don't like to be patronized into "not using my browser in full-screen mode" or anything the like...
You might try zooming in. Most modern browsers will zoom the whole page by default, not just the text. This preserves the page layout and uses more of your screen. Usually the shortcut is ctrl + + and ctrl + -. It works well on my laptop, at least
[Forget my mention of the windowmanagement, it wasnt on topic]
I currently run a big internet-community and we'll switch to fixed-width (for 1024px) design asap because we only get problems currently using a dynamic-width-layout: You cant rely on anything, and (the biggest problem imho) text gets to long, so there are only a few lines but the lines themself are much to long to overview.
Readability and Predictability
You need to know how things will be displayed to be sure it will be readable and pleasant to the eyes. By using a fixed width, you know exactly (almost exactly because of cross-browser support) what your users will see.
However fixed-width designs would be a thing from the past if browsers could support correctly exactly 2 CSS properties:
min-width
max-width
That would allow designers to design web sites that would be flexible and predictable. No more surprises and users can use whatever resolution they want.
In my experience, it is for two reasons:
1) Speed - it is generally faster to write a web page in fixed with, rather than trying to write one that resizes correctly at more than a small number of resolutions.
2) The designer of the web site isn't the ultimate approver of what goes into production - if you try to work with a flow instead of fixed layout you get questions about why it looks different on Sallys' PC vs the Big bosses, and why can't you move this over to here, etc, which are easier to fix by moving to a fixed layout.
Tabbed Browsers
Since I use a tabbed browser for day to day use, resizing my window every time I switch tabs is actually a bit of a hassle. I have the window set to the maximum usable width for my purposes, and to accommodate the "largest" tab that is open. For the remaining tabs, having fluid layouts is actually kind of annoying and distracting. Items and text jump around and change position depending on how I may have resized my window for another tab. Also, fluid layouts result in uncomfortably wide blocks of short (vertically) text.
For me, it's a lot easier as a reader to keep my eyes tracking properly on narrower blocks of text with lots of vertical scroll, and it's much easier when sites I'm familiar with stay the same size so that the layout and positioning is predictable, regardless of what I've done to my window to accommodate other tabs. I actually used to be a big fan of fluid layouts, but I find more and more that I prefer fixed layouts now that I use a tabbed browser.
I think the question shouldn't be "Why would you choose a fixed-width design?" it should be "why wouldn't you?"
Firstly, you need to cater for the lowest-common denominator. Many developers will be running on screens with resolutions like 1680x1050, 1920x1200 and 1280x1024. Some users will be using 1024x768, which I personally consider the lowest resolution you need to cater for (thank God it's not 800x600 anymore). If you fix the width to 960-1000 pixels then you don't run the problem of developers unintentionally making pages that can't be viewed without scrolling on a monitor with less than 1600 pixels (wide). Believe me it happens.
Layout on any non-trivial Webpage is hard. Throw in cross-browser support such that your page not only works but looks reasonably consistent and it's a huge problem. Now try to throw in variable width and it just gets that much worse if not impossible. Look at the payoff too: who is it going to benefit? A small minority of users that have high resolutions and actually want to stretch that content across the entire screen. I have a widescreen monitor and I won't maximize my browser for instance. Many people are like me in this respect.
Consider another problem: CSS. CSS s good for many things but is a royal pain in many others. For one thing. Now browser box model differences aside, there are still many quirks with how different browsers handle CSS and even if there weren't there are many trivial things CSS can't do and the only workaround is to do things by pixel.
As a concrete example, I'm doing some tables at the moment that are bursting at the seams. I'm reloading the contents with an Ajax call and replacing the contents. Now I at first tried to fix the widths of the columns with percentages. Doing it this way would be a prerequisite for not fixing the width. Firefox treated those as a suggestion and would resize them anyway even when it arguably didn't have to. I didn't get satisfactory results until I fixed the widths in pixels.
At the end of the day no website really cares if it stretches across 1600 pixels or not. That's what it comes down to.
I've worked with a lot of artists. They design a layout to be pleasing and clear. They want the presentation to match what they designed. Artist-driven design leads to fixed-width. For brochure sites, fixed width makes a lot of sense.
For sites with rapidly-changing content (news or shopping, or most anything driven by a CMS), I much prefer fluid, full-screen designs.
One of the biggest concerns that fixing the width of a website solves is readability. If you let a site be arbitrarily wide and have a block of text using that entire width, it becomes very difficult for people to read. If you make the font size bigger to compensate, then you destroy the experience for people with smaller screens.
On the other hand, if your content is visual or modular and you can make it fill up the page more intelligently, you might have a case for a totally fluid layout.
But I agree with the others who question why you would maximize a browser on such a big display. Why not make your browser window smaller? You'll be more productive and you'll stop worrying about it at the same time.
Many browsers do a better job of scaling websites to be larger than they used to; Firefox 3, at least, grows the entire page when you zoom in, not breaking the layout.
If you want it to take up more screen real estate, use a lower resolution. This can be useful if you're displaying a website on a large monitor up on a wall for public view. Otherwise, take #theomega's advice and use the rest of your screen for other windows.
As for a little (of the very little) of what I know about web design and fixed width sites:
They tend to make good use of white space and draw your focus down the page. Cluttering up the page by cramming every last corner with content is what designers call "visual intimidation." It's difficult to figure out what's important versus what's not.
They feel more "finished", like a picture in a frame instead of like a photo print thumb-tacked up on a cork board.
"It has a resolution of 1920x1200, so all fixed-width sites waste space
The form factor is only 15". So I have to use larger fonts and the text won't fit into these crammed layouts any more, sometimes even getting obstructed by other elements."
There is a good reason for that. If the paragraph are stretched too wide, it gets more difficult to read. Humans need a "break" after about 15 to 20 words and that is EXACTLY why we don't have books that are very wide.
The higher resolution allows you to have MORE details BUT it also depends on HOW you use the space. I never maximize the browser and PC's are built for window multitasking, not ONE window at a time.
The whole point of being able to adjust the size of your browser window is to better see the content of a web page, in the way that suits your situation. If the page isn't going to adjust, why not just make browser windows a single, fixed size?
If I have a big monitor, I want to be able to stretch my window out and have the content correctly fill it. If I need space for another window, I want to be able to shrink my browser window down and have the content correctly adjust by changing the layout (until a certain minimum point, and then by switching to a scroll bar, of course.)
Fixed width layouts are perfectly acceptable.
Fluid layouts are nice, but are more difficult to implement, especially if there are more than two columns and source div order is important.
Line length is an issue regarding readability, but this interacts with font size. So you have to balance width against likely font sizes on screen.
Nowadays, it's reasonable to assume that 1024 x 768 and up is the vast majority of the desktop user market, so you can safely design for 960 px fixed width -- for screen media type.
A couple of important constraints:
ensure is that horizontal scrolling
is never required by the user
if conversions are an issue, make sure
that clickable things -- particularly
"calls to action" or anything than
makes your cash register go
"ka-ching" should not fall to the
right of the 770th pixel or so --
just in case.
But another consideration is handheld media. You should provide alternate CSS for handheld media type. Many of these screens are under 400 px wide.
Delivering a site that looks good and functions on a wide variety browsers, devices, display widths and viewport sizes is a moving target and continuous challenge.
As regards the filmstarts.de site, it is definitely a mess, but the problem is not that it is a fixed width layout, but rather with how the layout is designed and implemented. There are good and bad implementations of fixed width layouts, just like there are good and bad implementations of fluid layouts, or semi-fluid layouts with fixed width elements, etc.
I put it down to laziness. Fixed width layouts are simply easier to design and make look nice because you do not need to worry about the size changing. This, for example, makes it really easy to add images, since you know what size the layout will be.
Personally, fixed-width websites really irritate me. I like to use large monitors. I paid a lot of money for them, so I'd like to make use to make use of them instead of having most of it be left blank. This is made even worse by sites which refuse to get larger if I increase the font size. I don't have the best eyesight and often use larger fonts to read text on websites and nothing is worse than a fixed-width layout leaving me with three words per line and a mostly blank screen...
As far as I'm aware while all the reasons cited are valid, the primary reason is that a lot of machines in monolithic institutions like banks and government orgs are still on fixed and somewhat archaic low resolutions. It's just the lowest common denominator sadly.
I personally like fixed width sites better. I am not forced to mess with my browser window to get a line size I can deal with. I personally find very long lines very hard to read. I also just think it looks better although that is 100% completely subjective.
I have designed and worked with both. Some aspects of variable width sites make displaying data easier. The only problem I have had with them is due to right aligned navigation which was a little messy when it could move based on the user's browser setting.
My final answer - both are fine and each have their place.
I just came across this site, which actually has a link in the top right corner that lets you switch between fixed and fluid.
http://developer.spikesource.com/wiki/index.php/Home
A major point for using fixed width is that the designer can actually control the way the webpage looks irrespective of browser environment. I see two reasons to use FW:
The designer wants the webpage to look all the same.
The designer lacks time/wish/... to test their page in different modes and in different browsers, and just avoids the risk of webpage layot starting flying around.
I didn't make fixed-size layout until I switched to a 32 inches monitor. It is very hard to read the text if the lines goes over 32 inches. I've learned appreciate text that do not span over more than 1,000 pixels, and I have switched to fixed layout since.
But I agree that reducing the content width to < 800px is a pain when you have a big monitor.
Most users lack understanding of how to use a browser properly. When the day come such that users actually know how to use a computer then you will understand that fluid width is the obvious choice for web sites.
I am frequently forced too. None of the 3 developers here has a strong background in design, and the dictated rules and implementations we strive for reflects this. It is an area I want to improve in.
Liquid layout using % as unit can adapt to any screen.
Some layouts must use fixed column design. If there's table or image in the column, you have to use fixed column, or the table or image will break the column in liquid design.
In grid layouts with heights of the grid normally fixed, it's better using fixed column or the widths may got uneven.
It's upto the content of webpage to use elastic column or fixed column layout.
Long lines of text can be difficult to read. For the website I work on we limit the width for usability and readability. We have also designed our site to scale well using CTRL-+ to zoom.
I find the concept of the programmable, tiling, keyboard-focuessed window manager ion3 very appealing, but I think it takes some time to customize it to your needs until you can really evaluate this totally different UI-concept.
Therefore, I would like to read reviews of people who tried it for a longer time as environment for programming (in particular using emacs/gcc).
(The policies of the ion3-author concerning linux-distros are not easy to follow for me, but this should not be the point here...)
I use ion3 daily. It's a wonderful window manager. The tiling interface really enables you maximize real estate. Once you get it setup to your liking, it is much more efficient to navigate via the keyboard. Even moving applications between tiles isn't that hard once you get used to the tag/attach key sequence.
With ion3, Vimperator and the various shells I have open during the day -- I barely use the rodent.
The author's opinions aside -- a good resource for configuring/extending Ion to your liking can be found at:
Configuring and Extending Ion3 with Lua
I've been using Ion daily for nearly two years now. Good things:
Easy to use from the keyboard.
Handles multiple screens (Xinerama) very well (once you have the mod_xinerama plugin), especially as in my case the screens are different sizes.
Very predictable where windows will appear.
Splitting, resizing and moving windows is very easy.
Multiple, independent workspaces on each screen.
Very fast and reliable.
Bad things:
Too many different shortcuts. e.g. there are separate keys for moving to the next tab, next frame, next screen, and next workspace.
Applications that use lots of small windows together work really badly (e.g. the Gimp) because it maximises all of them on top of each other initially.
Sub-dialogs can cause trouble. Sometimes they open in a separate tab when you want them in the same tab, or sometimes the open in the same tab and take the focus when you want to continue interacting with the main window.
These things can probably be changed in the config files, but I haven't got around to it yet. Also, the actual C code is easy to read, and on the few occasions where I've wanted to fix something it has been very easy. I don't feel tempted to go back to a non-tiling WM, anyway.
I've used it off and on for the last few years, I think its a great window manager, but I keep crawling back to kde3 whatever I use.
Its however difficult to put into quantifiable terms why this happens, but its right up there with the gnome-vs-kde battle. Neither side can understand the other.
I would also just love to have kicker + ion3, but they don't gel awfully well.
Moving applications between tiles ( something I tend to do lots ) also is a bit inefficient ( too addicted to the mouse )
( Kicker + Evilwm is a good combination, but evilwm just can't handle stacking in a user-friendly way )
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Pretty much every other editor that isn't a vi descendant (vim, cream, vi-emu) seems to use the emacs shortcuts (ctrl+w to delete back a word and so on)
Early software was often modal, but usability took a turn at some point, away from this style.
VI-based editors are total enigmas -- they're the only real surviving members of that order of software.
Modes are a no-no in usability and interaction design because we humans are fickle mammals who cannot be trusted to remember what mode the application is in.
If you think you are in one "mode" when you are actually in another, then all sorts of badness can ensue. What you believe to be a series of harmless keystrokes can (in the wrong mode) cause unlimited catastrophe. This is known as a "mode error".
To learn more, search for the term "modeless" (and "usability")
As mentioned in the comments below, a Modal interface in the hands of an experienced and non-fickle person can be extremely efficient.
Um... maybe there isn't much of a need for one, given that Vi/Vim is pretty much available everywhere and got the whole modal thing right? :)
I think that it's because vi (and its ilk) already occupies the ecological niche of modal editors.
The number of people who prefer modal and haven't yet been attracted to vi is probably 0, so the hypothetical vi competitor would have to be so great as to make a significant number of vi users switch. This isn't likely. The cost of switching editors is huge and the vi-s are probably already as good as modal editors go. Well, maybe a significant breakthrough could improve upon them, but I find this unlikely.
#Leon: Great answer.
#dbr: Modal editing is something that takes a while to get used to. If you were to build a new editor that fits this paradigm, how would you improve on VI/VIM/Emacs? I think that is, in part, an answer to the question. Getting it "right" is hard enough, competing agains the likes of VI/VIM/Emacs would be extremely tough -- most people who use these editors are "die hard" fans, and you'd have to give them a compelling reason to move to another editor. Those people who don't use them already are most likely going to stay in a non-modal editor. IMHO of course ;)
Modal editors have the huge advantage to touch typists that you can navigate around the screen without taking your hands off the home row. My wrists only hurt when I'm doing stuff that requires me to move my hand off the keyboard and onto the mouse or arrow keys and back constantly.
Remember that Notepad is a modal editor!
To see this, try typing E, D, I, T; now try typing Alt, E, D, I, T. In the second case the Alt key activates the "menu mode" so the results are different. :oP People seem to cope with that.
(Yes, this is a feature of Windows rather than specifically of Notepad. I think it's a bad feature because it is easy to hit Alt by mistake and I don't think you can turn it off.)
VIM and emacs make about as much user interface design sense as qwerty. We now have available modern computer optimized key layouts (see the colemak layout and the carpalx project); it's only a matter of time before someone does the same for text editors.
I believe Eclipse has Vi bindings and there is a Visual Studio plugin/extension, too (which is called Vi-Emu, or something).
It's worth noting that the vi input models survival is in part due it's adoption in the POSIX standard, so investing time in learning would mean your guarenteed to be able to work on any system complying to these standards. So, like English, theres power in ubiquity.
As far as alternatives go, I doubt an alternate model editor would survive a 30 day free trial period, so its the same reason more people drive automatics than fly jets.
Since this is a question already at odds with the "no subjective issues" mantra, allow me to face that head on in kind.
Non-Modal editing seeks to solve the problem caused by non-modal editing in the first place.
Simply put, with Modal editing I can do nearly everything without my hands leaving the keyboard, and without even tormenting my pinky with reaching for the control, or interrupting my finger placement by hunting for the arrow keys.
Reaching for mouse completely interrupts the train of thought. I have hated the intense reliance upon this with Intellij IDEA and Netbeans for many years. Even with vim-style addons.
Most of what you do has to do with fine-tuning with very small increments and changes within the same paragraph of code. Move up, move over, change character, etc., etc. These things are interrupted with control keys and arrows and mouse.
Though not really answering your question, there used to be a "modal like" way to write Japanese on cell phones before :
The first letter you hit was a conson let's say K, and then, and then the next key you would hit would have the role of a conson. (Having two conson in a row is impossible in Japanese)
Though it was main a few years ago, today it's only used by people who really want to hit fast.
I think the answer to the question is actually there are quite a few modal text editors that aren't forks of vi/vim. However they all use the vi key bindings. Vi users get the key bindings into their muscle memory so relearning a different set of key bindings would be really hard, so no-one would create a different set of key bindings.
But lots of different editors have re-implemented the vi key bindings from scratch. Just look at this question about IDEs with vi key bindings. At least half of the answers are editors built from scratch that implement vi key bindings, not versions of vi embedded.
I recently came across divascheme - an alternative set of key bindings for DrScheme. This is modal, and part of the justification is to do with RSI - specifically avoiding lots of wrist twisting to hit Ctrl-Alt-Shift-something. The coder has done an informal survey of fellow coders and found that emacs users suffered from more wrist pain than vi coders.
You can see him doing a short talk at LugRadio Live USA. (The video is a series of 5 minute talks and I can't remember how far through it is, sorry - if someone watches it and posts that here I'll edit this post to say when in the video it is).
Note I have not used divascheme.
The invention of the mouse took one mode and moved it to an input device, and context menus took another mode and moved it to a button. Ironically, the advent of touch devices has had the reverse effect, producing multi-modal interfaces:
aware multi-modal - touch and speech are aware of each other and intersect
unaware multi-modal - touch and speech are unaware of each other and conflict
The traditional WIMP interfaces have the basic premise that the information can flow in and out of the system through a single channel or an event stream. This event stream can be in the form of input (mouse, keyboard etc) where the user enters data to the system and expects feedback in the form of output (voice, vibration, visual, etc) when the system responds. But the channel maintains its singularity and can process information one source at a time. For example, in today’s interaction, the computer ignores typed information (through a keyboard) when a mouse button is depressed.
This is very much different from a multimodal interaction where the system has multiple event streams and channels and can process information coming through various input modes acting in parallel, such as those described above. For example, in an IVR system a user can either type or speak to navigate through the menu.
References
User Agent Accessibility Guidelines working group (UAWG): Keyboard Interface use cases
W3C Multimodal Standard Brings Web to More People, More Ways
Next steps for W3C work on Multimodal Standards
The Future of Interaction is Multimodal
Beyond Mouse and Keyboard: Expanding Design Considerations for Information Visualization Interactions - naturalinfovis_infovis2012.pdf
Setting the scope for light-weight Web-based applications
Jan. 26, 1983: Spreadsheet as Easy as 1-2-3
Multi-modal design: Gesture, Touch and Mobile devices...next big thing? | Experience Dynamics