Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Usability suggestions to Twine
Hi! New here, I already made a question but this is just-another-annoying-suggestion thread.
I'm a game designer and I love what I can do with this engine, but I'm having major problems with the usability of it, so here are some suggestions that you will surely hate from the developer's side:
1. Inline editor: I don't know why this isn't implemented. Currently, to change anything, you need to double click a "post-it", then edit, then save or close the "post-it". If we had an editor (say, divide the screen in two columns, one for the map, other for the editor), everyone's lives will be easier. Having to save all the little changes we make once and again is really unproductive.
2. A button on the Taskbar for "Test Play". Pretty please? It will save us one click. Editable taskbar would we awesome too.
3. WYSIWYG editor: Yes, I know, just click on Test Play. But usability is about saving clicks, so... having a browser inside Twine that's triggered by any changes we do, could also save us tons of time.
And that's it! I think the rest is great.
I'm a game designer and I love what I can do with this engine, but I'm having major problems with the usability of it, so here are some suggestions that you will surely hate from the developer's side:
1. Inline editor: I don't know why this isn't implemented. Currently, to change anything, you need to double click a "post-it", then edit, then save or close the "post-it". If we had an editor (say, divide the screen in two columns, one for the map, other for the editor), everyone's lives will be easier. Having to save all the little changes we make once and again is really unproductive.
2. A button on the Taskbar for "Test Play". Pretty please? It will save us one click. Editable taskbar would we awesome too.
3. WYSIWYG editor: Yes, I know, just click on Test Play. But usability is about saving clicks, so... having a browser inside Twine that's triggered by any changes we do, could also save us tons of time.
And that's it! I think the rest is great.
Comments
#3 sounds like way overkill to me. #2 sounds nice and easy to implement, although I could take it or leave it.
I've suggested something similar to #1 in the Twine 1.4.2 thread...that is, a much better, industry-standard-like Find and Replace function. Currently, you can't *see* the individual instances of a found string to know if you really want to replace it or not.
I don't really think an inline editor would be better than what already exists visually, because I use Freemind to map my Twine game, and it has an inline editor, and splitting the screen definitely has its disadvantages. But I do think Twine needs better global editing capabilities, and if an inline editor brought that, I would welcome it.
I've moved to editing a .twee file in Notepad++ plus using Freemind for the above reason. That, and Freemind organizes nodes in a user-friendly, logical pattern, whereas Twine does not.
That said, of course I love the core functionality of Twine. It makes writing these kinds of games very easy.
See what I'm talking about? For a power user like you, your needs aren't satisfied by the current implementation of Twine, so you had to get external help with two different softwares. That screams bad design =P
I don't want to have to use another software! Nor should any kind of user (be it novice or power user). Hope some of these get added eventually.
I'm using Twine to compile the game and of course I'm using Twine's language! The link syntax, the if/then syntax, all of that. That's what I love. Very easy to understand and write.
Re: 1. Inline editor
One downside of the "Inline" style of editing is that you are generally unable to see the properties/attributes of two objects (passages) at the same time. Depending on how an Author likes to work this could cause major workflow issues.
Re: 3. WYSIWYG editor
Inserting a html renderer into the Twine GUI is not a trivial task and the first issue to solve would be Which Renderer?
Twine runs on three OS (Window, OSX, Linux) and each of these has their own default renderers (Trident, WebKit, Gecko??) each of which has their own method of embedding and API.
If the decision was to support the default renderer on each OS an abstraction layer would need to be created that could interface with each of the three.
note: Trident does not support HTML5 on WinXP
Another option would be to choose a renderer engine that supports all three OS and to use that instead but then we either have to supply the renderer engine inside the Twine installer or tell the users to download / install the selected web-browser.
What do you mean about this?
[quote]Re: 3. WYSIWYG editorIf the decision was to support the default renderer on each OS an abstraction layer would need to be created that could interface with each of the three.
Exactly. The decision isn't up to me, but the developer. I'd say, aim for the market with most future (Chromium).
The inline method you describe consists of a Story Passage map on one side of the screen and a property/attribute editor on the other, and each time the Author selects a Passage in the map the property editor shows the tilte / tags / contents for the selected passage.
How does the Author see the properties of two passages at the same time if they want to compare them?
[quote author=notnsane]
Exactly. The decision isn't up to me, but the developer
My point was not that you had to make the decision. The point was that a hard decision would have to made (use OS defaults or select same one for all OS) and that both choices have downsides that could stop people from being able to use the Twine GUI.
[quote author=notnsane]
I'd say, aim for the market with most future (Chromium).
I was reading an arstechnica article only yesterday that stated that Chrome based browsers have less than 17% of the Worldwide Combined Browser Market share. While this report is only one among many and its number may not be 100% correct, it still indicates that it is not safe to just support one browser/render engine.
That said, I really don't see the point in a WYSIWYG version. The story formats aren't some largely static source that gets compiled into mostly plain HTML (where a live-preview could be both feasible and sensible), they're full-on JavaScript web apps. Any time a project's passages were modified (added/removed/edited) the compiled web app would have to be both recompiled and reinitialized, which makes a live-preview largely infeasible. Coupling an HTML rendering engine to Twine gains you nothing over the current situation, where you view the compiled web app in an external browser. Twine isn't Markdown Pad (as an example of where having a WYSIWYG mode is feasible).
PS: Don't confuse Chrome/Chromium and Blink. Blink (Google's fork of WebCore) is the HTML rendering/layout engine used by Chrome/Chromium and Opera (15). Chrome/Chromium are full-on web browsers.
The ability to draw (filled polygons) and write annotations on the story map background might be nice to help me visually organize my passages a bit better - Friday morning, Friday afternoon, Friday evening, Friday night with different clusters for, say, The Bar, The Alley, The Police Station etc...
1) is an interesting tradeoff. I think the inability to open two passages alongside each other is one of the biggest weaknesses of 2, which uses a modal approach. From a GOMS point of view, one click is certainly faster than two.
The reason why I'm going with a modal approach right now versus an inspector pane is because I am targeting tablets too, and I'm don't think that would work well from a screen space point of view.
2) is already implemented as of preview 4. Thanks Leon!
3) is where I want to go with Twine 2, but not for the 2.0 release. There are complexities to WYSIWYG because you may be viewing a passage with conditional logic -- what should that do? Should it just show the code? Doesn't that kind of defeat the purpose of a WYSIWYG view? Should there be a test playthrough"similar to what Inform 7's IDE does?
With regards to seeing just the code for the conditional logic in the editor, I think Dreamweaver just has a box when it comes to anything that's marked as code or anything embedded (having said that, the last time I had Dreamweaver installed was 2012 so it may have moved on since). While that makes it a kind of "pseudo" WYSIWYG, it would be a solution at least. If the user has it so that it's
<<SILENTLY>>, you could maybe just have a little icon that expanded to show the code if it was clicked or something.notnsane: Usability isn't just about saving on clicks, and in fact there are certain areas where a few extra clicks here and there can be beneficial. The area of "connecting" and interacting with the software is one.
When I say connecting, some of the most boring programs I've ever used have been point and click. Yep, it's been quick, but it's also felt too efficient. It's like there's some sort of business transaction going on between me and the program as opposed to the program seeming to "help" me. If there's minimal interaction you feel disconnected and out of the loop. If you need to click a couple of things to do something occasionally it's no bad thing.
I know when it comes to tablets then less is definitely beneficial, but I really couldn't imagine using Twine on a tablet; the autocorrect for the on-screen keyboard would probably go into meltdown for a start, and then there's the issue of things such as < and [ not usually being easily accessible from said keyboards. That is purely my personal preference and I dare say there are tablet users out there with bluetooth keyboards etc, which will no doubt make the job easier.
That's extremely subjective. And usability isn't about "less clicks", it's about saving time, and making an application easy enough to use you can use it without a manual. That usually involves "less is more" mentality (but always with some options for power users like Nielsen recommends).
The complete opposite of that is, p.e. The Lord of the Rings Online. Everything is so customizable it's completely overwhelming, the options must have like hundreds of them. Very unnecessary.
For me it is about intuitiveness (how easy is it to learn) and productivity (get things done), and I would rather use keystrokes to achieve a result than use a mouse. But this is not the same for all people.
The same can be said about the level of custom ability of an interface, some people like to change the screen layout / key-binds of an application and some don't.