Jump to content
Storyist Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ross_h

  • Rank
  1. I noticed the same slight lag with the keyboard and especially with the lock screen password. There is an easy but annoying fix for this- settings/general/reset/reset all settings. You'll have to go back and turn off all those battery killer features again, your wallpaper and wifi password, but at least the keyboard won't be laggy anymore. One other thing- when I did this, I found the keyboard click stopped working. Finally figured out that as I was using the lock switch to disable screen rotation, when I reset all settings this switch reverted to it's default setting of muting the sound instead.
  2. I do think that iOS 7 is very much a work in progress. Just looking at the inconsistency in app icons being either flat colored or shaded dark to light or light to dark demonstrates that. Using color to distinguish labels from buttons will become second nature in a while but it's very dependent on how well the UI in an app is designed. Having white as a dominant background I think is a mistake, and something Storyist has thankfully avoided especially with the project view being that nice dark blue grey that keeps your focus on the writing. The new look for iOS7 works great, but I think that's down to the design (it also looked great in iOS6) of the app rather than the design of iOS7! Clean, intuitive and functional. My criticism is really a criticism of iOS7, I wouldn't change anything you have done to the app- it matches the new style and design philosophy perfectly. And thanks again for adding novel support for fountain. Now I have no excuse to start writing all those ideas I've filled many notebooks with!
  3. Hi Steve, I updated to iOS7 a day after the release and I'm still not sure what to think of the redesign. While I agree iOS 6 does look a bit dated, there's a deja-vu to a lot of the iOS7 visuals too (flat shaded, frosted transparency). But whereas there has been a trend in UI's to go to a darker charcoal grey (at least for art apps), Apple have done the opposite and gone for a pure white, which I find quite glaringly bright and hard on the eyes. Borderless buttons and ambiguous icons do make navigation a little trickier too. I'm not sure the visual language has been locked down yet. While the older iOS had a dated look, the rounded bars and buttons did at least give you some separation between parts of the UI. For me, I think there is more change for change's sake than for improved functionality, and a ripping out of any trace of skuomorphism. I never had a problem with skuomorphism, as long as it was done well. It added a certain (pseudo) tactile familiar 'feel' to any app that used it, and often it aided in adding a touch of nostalgia and atmosphere and made you forget you were using an electronic device. No-one complains about using an analog clock to show the time, because it's a better display to use than just having digits. Yet it emulates the look of a mechanical device. Bad design and user interface I feel was the bane of trying to emulate reality though, where form took over function. But even now, in iOS7 we set preferences by 'pressing' a visual representation of a toggle switch that by all visual clues should be slid left or right. That, is bad skuomorphism, not fake leather trim on a notebook. A lot of the new iOS7 features also appear to be battery sappers, so whether you like them or not, one of the first things to do after upgrading is to turn them off. The parallax wallpaper looked a lot better in the online videos than in real life, and is a not so great solution to the lack of separation of your app icons from the wallpaper (something iOS6 did just fine). Storyist seems to have made the transition to iOS7 quite easily, no doubt thanks to the nice UI design. There are a few things I miss though- as overdone as the linen wallpaper was, there's something to be said having untextured index cards on a textured background. Negative space draws your eyes to the cards and not the background. Sections in the outliner used to be separated with some bevels, rather than just listed on a solid block of color. However, the 2-tone keyboard I prefer in the new. The notes are a little out of place now too, as they still have the skuomorphic look of a post-it note in this otherwise more abstract interface. But these are extremely minor criticisms. Storyist is a well designed app and the update to iOS7 has a very familiar look and retains the colors and contrast of the older version. Oh, and the addition of fountain support for novels... a very pleasant surprise. ;-)
  4. Storyist 2.1 now supports fountain files for novel writers. To get this working, you need to add: Type: Novel ...at the start of the plain text .fountain file you want to use. When you import this file into Storyist, you will get the novel keyboard layout (and not the screenplay one). .
  5. Hmmm, so I've done a few more tests with .fdx and .fountain files. Seems like you can import these files into a .storyist project and they stay as those file types, as long as you import them into the root level of the project. Importing them into a folder within the project and they lose their original properties and cannot be saved back out as the same file type. You also have to manually export and import files with Dropbox (although you can just sync the project easily enough), but it at least gives you some flexibility. I guess you could always keep the files loose at the project level and then copy them into .storyist projects once they are pretty much done editing. That way you don't end up with the project view full of loose text files.
  6. Firstly, let me add my thanks for a great v2.0 update. I love the new project navigator and the slide to reveal/hide functionality. The versioning was something I was interested in having but the auto-30 day backup sounds like something that will give users a lot of peace of mind. Anyway, my suggestions for additional features are of use to those of us who don't plan on using native Storyist projects. I'm a little wary of proprietary file formats/XML that if something goes awry you need to dig in to rescue your work. I'm willing to sacrifice data clarity for ease of use, but my ideal workflow would allow me to work on either my desktop or my iPad via the elegant Dropbox sync workflow. But as a non-MAC user, .storyist files are not a format I can edit on my home computer as there is no Storyist for Windows. Importing files into a storyist project seems to convert them to a storyist file, and while you can export the file out and back in again there is some conversion going on during the process. Fountain files I don't think can be handled this way. Now I can choose to work in .rtf, or import either a plain text, .fountain or .fbx instead which is great but I can foresee my project view being filled up quickly with individual files (chapters in a book and for instance) rather than collections of related files. Here are my suggestions of features I would like to see to improve the non-storyist workflow: 1. While its easy to import plain text, fountain or final draft files into Storyist, why not add the option to create a blank file of each format (like you can with .rtf text files) from the project view. 2. Non-Storyist 'projects'. The current file hierarchy is flat, which is not an issue with .storyist files as they can have nestled folders inside them. So while the Storyist project is really a single file on disk, it acts like a normal file structure. Would it be possible to create a non-storyist project, that is a blank folder at the project level. Additional levels of nestled folders would be great but not essential by any means. This would allow us to keep collections of files together similar to how a Storyist project works. I still see wanting to sync individual files in the folder as if they were at the project level; maybe all the files within the project folder could be synced together if you select the folder at the project level. Of course, I need to do a lot more writing with Storyist before I have to really worry about a cluttered project view making it hard for me to locate files, but I'd still like to see all files at the project level being handled as project containers rather than projects and loose files. Anyway, just wanted to finish up by saying how much I love Storyist. Anyone who actually puts cursor keys on an iOS text editor understands how people really type. That feature right there is enough to make me want to use Storyist!
  7. I can write and edit with the project list view open, you just need need to pin it in place first.
  8. The title page support makes sense, however I did created the initial screenplay document in Storyist rather than starting as a fountain text file, which puts a FADE IN: automatically as the first line. I edited this to be a scene heading (and added the other parts of my test) before exporting to Dropbox as fountain. Turning this first line into a heading would be a more than acceptable solution. The split-line comment syntax I tested I took straight from http://fountain.io/syntax, which I would assume to be official. But I mentioned it more because of the way Storyist has you typing notes in a virtual stickynote, that is is very tempting to make your note more legible by using separate (and the odd blank) line as you would with a bullet point list. While not essential by any means, it is the only practical part of this that the organization isn't retained between Storyist and fountain. Well that and index card colors. I experimented a while ago with a python script and the Index Card iOS app to convert between the apps simple xml format and a pseudo fountain-type plain text syntax. I'd tried with Storyist but found the .storyist xml too complex to decode and to duplicate in plain text. By adding the color after the index card xml name (for instance, ".Scene 1[blue]"), I could easily retain any coloring I had done in the app and even add some if I could remember the colors when working in a plain text editor. Unfortunately I ended up experimenting with python more than I did with the app and while the index card and colored synopsis display is excellent, the actual synopsis and body text input leaves a lot to be desired. Not something I would want to write for long periods with, certainly. The recent addition of fountain support brought me back to Storyist, and the workflow I had originally wanted to pursue but found I was unable to in the otherwise excellent app.
  9. Had another play with this tonight and it seemed to work vey well using scene headings for index card labels and actions for body text (especially as it automatically defaults to action after a scene heading). I even got the nested sections using the heading1 - 3 style to work. I did however find one or two issues. The first scene heading while remaining in the manuscript view, loses its name (becomes "Introduction") in the index card view. The synopsis is also lost, although the comment I added was still there. I deleted the FADE IN: to create this first heading, maybe this was a mistake. Comments, where blank lines between comment lines either didn't export to fountain (only the first line did, this happened once but I couldn't get it to happen again) or hitting enter at the end of each line exported as a space. Importing had the same issue where the fountain syntax wasn't strictly followed, where the comment in square parentheses below wasn't interpreted as a comment but as normal text: ---- His hand is an inch from the receiver when the phone RINGS. Scott pauses for a moment, suspicious for some reason. [[This section needs work. Either that, or I need coffee.Definitely coffee.]] He looks around. Phone ringing. ---- ...the 'blank' line splitting the comment actually containing 2 spaces, as per fountain syntax. This also happened with synopses with either linefeeds or blank lines although I don't think there is a way to have blank lines in synopses using fountain so that's hardly surprising. Otherwise, it worked better than I expected. Very happy.
  10. Hi Steve, yes I agree that fountain gives pretty much all I would want, more so than markdown. Unlike markdown, fountain does do some contextual parsing based on capitalization and line spacing rules (rather than tags) which may cause some issues in importing/exporting of a more loosely structured non-screenplay manuscript. My thought wasn't to define a new syntax but to maybe allow for a more limited import/export using a subset of the fountain language; only those hierarchical elements that are actually defined in the manuscript with the rest assumed to be (action?) text. Still a valid fountain file, but one without any the screenplay specific elements. The scene heading syntax for Storyist sections didn't bother me (a small price to have labeled index cards) although I failed to get heading-level sections created by the # symbol, although in my brief test I didn't center the symbol. Defining the body text as 'action' may work better than 'unformatted, which is how I tried to do it. I will do another test tonight and see if I can get it to work. I'd still like to be able to do this from a novel document setup, rather than having to use the screenplay onscreen keyboard but it's something I can certainly live with if I can get my test tonight to work.
  11. I didn't pay much attention to the .fountain support in v1.3. I've always liked the idea of the markdown type metatagging you can do in plain vanilla text files, but I'd rather just write than worry about formatting the text until much later in the process. One thing that has kept me from using Storyist is the prorpietry format of the storyist project files. I want to edit a manuscript on my PC as well as my iPAD, bouncing between the two via Dropbox. As I don't own a MAC, I don't have any way of accessing my files outside of my iPAD. Yes, I could just export as a text file, but that would mean I'd lose any metadata (such as synopses or comments) when I reimported the file. I then started experementing with final draft format, still a propriety format but one at least that several 3rd part editors can import/export. But I finally tested out .fountain and was delighted to find out that Storyist parses the text file and allows you to work as if it was a normal screenplay document. It also saves your synopses and comments, as well as the index cards when you export as a .fountain text file. Now it's not perfect. I found in a simple test that I'd loose my first synopsis and index card label when I'd export then reimport the file. Corruption seems to increase if you keep simply exporting and reimporting, probably due to the heuristic contextual processing of screenplay elements that don't have definitive tagging. It als doean't seem to support the section tag ("#") which I'm sure everyone recognises from the novel manuscript format. However, it does seem to be a nice way of using the features of Storyist (excluding index card colors) while remaining in plain text format. I wonder if this import/export ability could be extended to the novel format and not just the screenplay. In fact, maybe it would be better to have a subset of .fountain tagging that could be done to novel manuscripts rather than potentually accidentally tagging upper case words as action or dialog: Scene Headings (index card labels). Start line with a period - .The Factory Notes. Encase note in double square brackets - [[this is a note]] Synopses (text on index cards) - start (and end?) line with equals sign. =this is a synopsis= Sections. Use # symbol at start of line (up to 3 deep) - #Chapter 1 ##Beginning ###Intro #Chapter 2 Other formatting commands could be added, for bold or italic text for instance, but anything not tagged would be considered body text. Most of this can of course be done right now, just using the screenplay template to begin. However I think having a subset of fountain available to use (that won't confuse body text with screenplay tags) I think would be very useful.
  • Create New...