South Lake

So it looks like a a new product taking clear inspiration from Journler is coming. Version 0.1 should be available by the end of the month. Here’s a glimpse:

southlake

The project’s name comes from the area where I currently living, South Lake. It is open source but there will be a business model (I’m charging for it). There is a grand vision for a cross-platform tool initially tailored to researchers of all kinds, but the initial prototype will be Mac only because I am most productive developing for that environment.

What you’re seeing here is a working application using Markdown and LaTeX to render equations from information theory. But I was thinking just yesterday that’d it be the perfect tool for organizing and preparing my taxes.

 Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin

20 Replies to “South Lake”

  1. Hoping this will include simple solution for syncing between Mac and iPad versions, WITHOUT cloud storage being required. And, of course, a way to import old Journler files that preserves all formatting. I’ve loved Using Journler all these years, so can’t wait to finally have an up to date successor (happy to pay for it too). Thanks for your hard work.

    1. You might not like this response. =) At some point I’ll be making a longer post about the vision for the application and design decisions, and that impacts how syncing and compatibility might work.

      Regarding syncing, the short of it is that I’m aiming for a fully cross-platform product, so I can’t use platform specific technologies for a lot of functionality, including syncing. In the end that means there will have to be some kind of cloud based technology for syncing, and it won’t be iCloud or any other Apple, Google, Microsoft, or Linux specific technology.

      As for Journler compatibility, at this point the application is a complete break with Journler and offers no compatibility. Journler does a couple of things very differently. It uses the rich text format for its own entries (RTF files), which I now consider to have been a major mistake. This application uses Markdown, which ends up as HTML. It might be possible to offer an RTF to Markdown converter at some point, but I suspect that it won’t preserve all the data.

      More significantly, Journler treats files as second order documents. In Journler a file can’t exist by itself. It has to be attached to a text entry. That goes back to Journler’s legacy as a journaling application. This application is a “project based information manager”, so files are on equal footing with text entries and can exist independently of them. There is no immediately apparent way to preserve the relationship between text and files that Journler requires if you import them into this application.

      1. Philip, thanks for the feedback. The biggest downside of most ‘cloud’ syncing solutions would be removed if, as you seem to suggest, you can free the user up to choose their own remote-server from at least a wide range, if not open ended, set of options. Ideally, there would be some LAN/WAN central file-server-as-cloud option as well, but I understand if that’s beyond the scope of your project; it would protect institutional data better, if implemented at the enterprise level that way (think corporate research facilities). And it would be great for those of us who live part time ‘off the grid’, enabling easy backup and syncing in remote locations. Just a thought.
        I totally understand now why importing Journler entries is not feasible. Oh well, it was worth asking for. Journler was such a perfect little tool for so many research, and creative, projects. 🙂
        Thanks again.

        1. One thing I’m considering and definitely struggling with is how to use the filesystem. One approach has the application store data the same way you would normally: have actual folders and files and a one-to-one correspondence between the document hierarchy in the application and on the filesystem. There are consequent limitations to how you can organize your data and some difficulties keeping the database in sync with the data. The second option keeps the files stored in some internal, opaque way. The application then models the document hierarchy internally using the database.

          The second way is easier and is how I’m prototyping the application right now, but the first way keeps the data accessible outside the application and allows you to do whatever you want with it, including, say, syncing it to dropbox, using a lan, or using git. This wouldn’t keep the metadata in sync because that responsibility belongs to the database, but it gives the user much more control over the files, and this is very appealing to me.

  2. Just a thought: your “second way”, I’m imagining, is like the flatfile, quasi-database approach of MS-Access in its earliest incarnations? And if so, I see why that would be much easier to control and sync, but what about the possibility of a hybrid model: you would have real folders and files, wherein the text/data/images reside, and then you would have a flatfile database which serves to link/associate all of those documents, and this would be where the metadata resides, and where syncing-data is parsed by your app. Your app would then organize using the database, but populate its UI ‘fields’ with content from the docs themselves. You could even have a field in the flatfile DB that holds a bit of content from each doc, so that thumbnails/previews would be instantly available. I’m not a developer, and so maybe this is an obvious option? But I think it would give you the benefits of both, and if you built it around some open source DBMS, it would be easy enough for anyone to set up a server host (even a non-techie like myself), with documents and folders that are still identifiable, and easy to use outside of the app.
    Sorry to dominate your forum here. Drop me an email if you ever want more naive user-feedback. 🙂

    1. It’d be very similar to what you’ve described. The database would be tracking the metadata and caching information about the files, but yes, the ui would load directly from the files themselves.

      I really like this approach for the flexibility it provides to the end user, but it does introduce difficulties. The db I’m using needs to track files itself, so it would duplicate everything whenever a sync occurs. Maybe that changes if I move to a different system. The app would also have to watch every file for changes that occur outside the application and re-index and re-smartfolder the files. Not impossible.

      Moreso, the unavoidable design difference is that a file can now only belong to a single folder,because it now resides in an actual location on the file system that is mirrored in the application. In Journler a file can belong to many folders. I might be worrying about a use case that doesn’t really exist, so this may not be a major disadvantage. The program ends up working like the Finder or Mail, instead of say iTunes, which isn’t crazy.

      Naturally I will be happy to get your feedback! I’m hoping to release a prototype around the end of this month. It will be minimal but it will provide a definite sense of the direction I’m hoping to go. I’ll have more information here as I get closer to that.

    1. I was planning to have it out this week but got crazy busy. I have what I think is a week or two’s worth of work to get basic importing and search working. Everything else for the 0.1 release is otherwise usable. So close! =)

  3. Great News! I bought and still using Journler even today and it is a great tool. If there is any chance to help in beta testing or giving feedback i’m here to help as well. Looking for a future proofen tool as well for Journler and would be really interested in your new approach. Of course having an import tool into the new application (even if it’s only partly possible) would be great. Looking forward to find some updates here.

  4. I’m very glad to hear about this new project, after more or less giving up hope that there would be software as good as Journler in my future. Maybe I’ll finally be able to move on from my old Macbook Air with the broken hinge and almost non-existent battery life, not to mention assuage my guilt about not paying for Journler after using it from approximately 2007 (my computer says 1904, but I don’t believe it) to 2013. Look forward to hearing about more about the vision and the new release. Thanks 🙂

  5. This is very exciting. I’m a lawyer, looking for an alternative to CaseMap and came across references to Journler. Switching to a more markdown/plaintext based engine and offering cross platform access (especially iOS) are two very appealing factors for me.

    If you ever decide you want beta testing help, or feedback from the point of view of a law-based user, just let me know.

    1. Hi Ciaran,

      I’ve thought about building the product initially for a specific market. I learned some time ago that there were a number of lawyers using Journler, and it seems like there is still an interest from that market segment in a Journler-like application.

      You mention that markdown/plaintext and cross platform access, specifically mobile, are important for you. Can you tell me why else CaseMap isn’t the right product and what other functionality is essential?

  6. Is there going to be support for video capture in this version? I’ve wanted to use Journler, but the video capture keeps failing on me. Other than the capture, Journler’s video support is above/beyond other apps I’ve tried.

    1. Maybe. I’d most likely suggest that you try QuickTime Player. It has built-in support for video capture. Have you used it before and just don’t care for it?

  7. Good to see you are still working on new projects.

    I used Journler all the time still, albeit for relatively trivial info.

    One of the key aspects for me, that no other similar app I’ve found has, is the ability to link entries. Being able to track the history through links is very useful.

    1. Wiki-like entry linking and browsing history are definite features. Neither will appear in the earliest releases (I should just post the dang thing already!) but I consider them essential.

    1. How about a release today? =) Well, we’ll see. I’ve been sitting on this early version for months and playing with it again I find a few bugs that I would want to fix.

  8. If you can keep this the best vanilla-flavored cross-platform, I (and many in my maker group) will be all over it. Our dominant OS is Debian, but there’s Arch and the usual suspects of a hackerspace. One problem we have is sharing formats (we don’t use what most call the “cloud”, we rolled our own “stallman box” but I’ve noticed there’s less Mac users every meeting. Keep it up, My journler on my elderly mbp will keep plugging along until then.

Leave a Reply

Your email address will not be published. Required fields are marked *