Several Suggestions

[MHM5000]

Just a couple of suggestion:

1. Internationalization: Translations could get the product on more front pages than you think.
2. Localization: For example in Iran, Fridays are the end of the week and we have 'Shamsi Calendar'. Arab countries and, in general, Muslims have another calendar called the 'Hijri Calendar' (where Ramadan comes from). I'm sure there are more calendars out there as well.
3. A timer: I personally don't have a lot of time on my hand, but documenting stuff could help me more and more. A simple clock/timer on the page could be of great help so that I wouldn't lose track of time. Also, consider creating this in a way that people be able to select/create different clocks (digital/analog) and change the themes. or have a couple of options ready to go with the theme.
4. Although offline is good, simple option of syncing to dropbox/google-drive would be a great option. Still, everything should be on the client-side.
5. Markdown should be easy to implement, but a more advanced WYSIWYG editor, with a switch in settings, shouldn't hurt.
6. Todo lists should be easy to implement too.
7. We don't have letter-spacing in Persian, Arabic, Pashto and other languages that their alphabets have joined forms. It makes them ugly.
8. Also, there are a lot of amazing open-source fonts for better Typography.
9. All of these suggestions could be simple plugins that after activation get downloaded, so the site would be as fast as it is right now. I'm not saying you should implement them all, these are just open suggestions that need more polishing. Even google's version of Hijri/Shamsi Calendars gives me headaches! They are extremely useful, but nobody cares.
10. The ability to password protect the entire journal could come in handy.
11. Maybe even creating multiple Journals.

Let's figure out which ones to do and when to do them.
Even maybe look into crowdfunding for making these ideas real.
Copied from #33 .

[johannschopplich]

My two cents regarding:

1. I'ld be happy to contribute the German translation!
4. Oh yes.
5. Actually I like the simplicity of having no editor functionality at all. I'm writing markdown anyway but would't like syntax highlighting etc. Anyway other may like an advanced editor. If it stays optional, I'm in. 🙂
8. For a more consistent native app feeling I'ld stick to the native font stack. I prefer it over any great typeface (even Inter UI).

Crowdfunding is a great idea! This app is just so incredible and lightweight.

[MHM5000]

1. That would be amazing.
5. Everything should be option-based in this app beyond this point.
8. The native fonts for Persian on pretty much every OS out there are horrendous.

Arial looks like you want to stab the users' brains out, Tahoma is just there for you to get your eyes out on counting the Titles in letters (the only letters in English with a Title in them are i and j). Just a couple of them in Persian: ش, ث, ت, غ

They also have multiple forms: ش, ـش, ـشـ, شـ. You can just imagine how painful is to create new fonts! And how expensive. Yet there are several amazing open-sourced fonts adjusted for Persian reader eyes in small sizes.

At the end, look at Persian Calligraphy.

[johannschopplich]

5. Absolutely. 👍
8. Oh boy. 😲 Didn't thought about that. Makes absolutely sense... Which font do you prefer? Is there a good open source one with decent Persian support? Like Roboto?

[trys]

1. Sounds great! What's the preferred domain format for translations?

• Subdomains are neat but each translation will be it's own PWA (for better or worse, could that be handy for some people).
• /en/:date or /en-gb/:date could also work
• Do we even need to reflect the language in the domain? What does that offer for a personal app?

Also, is there work that can be done to improve browser auto translation? Date formats will no-doubt need considering for this.

2. Very interesting, so would you see this as a feature for the pages under the calendar icon for going back in time to see previous entries, or more/differnet than that? Currently that section uses /:year and /:year/:month so I'd be really interested to get your advice on how to best navigate each calendar.

3. How would you see this working? Would it be something you'd start/stop to document how long you're writing for? Just trying to understand how it would integrate with journalling - full disclosure, I started JournalBook to help me start journalling so I'm very much a novice in this field!

4. Absolutely, one of the biggest comments from the HackerNews influx was syncing. Totally agreed that it should stay client-side and just do optimistic syncing as a backup. It'll need a lot of thought over diff'ing and will probably mean a migration from the key/value entries table over to proper objects (oh how I wished I'd done that before publishing this!), so we can store timestamps and more entry data.

5. That would be real nice, maybe as an opt-in? Snarkdown looks great, and means we continue down the Jason Miller brilliant and tiny package rabbit warren! 😂 That might open up a wider point about edit mode vs. reading mode. Currently, everything is a textarea, so you edit immediately. It would probably be worth transitioning to an edit mode (automatically active for the current day), and a reading mode (potentially markdownable). We'd probably need to store the format for each entry to allow for future conversion.

6. This definitely seems like a great feature, but I think we'll have to be wary of not overstretching the app from it's core goal. Personal journals are often used as todo lists so this'll be perfect, just somthing to keep in mind. There are loads to TODO apps, so we'll need to pick which features to go for, and draw the line somewhere.

Personally, I'd rather this app be seriously great at a few things, rather than push too many average features. But I'd be really interested in your thoughts! Maybe the goal needs to be widened to making the best 'paperless journal'? So anything one would do on paper, we should aim to recreate?

Going back to todos! My initial thoughts are that this would sit as a separate area, but perhaps integrated into the daily writing area somehow. Todos with 'due' dates would be really neat, we could do a home page 'coming up' section with the ordered todos. We'd probably need to open up future dates (currently being redirected back to today).

7. Oh wow! That can be dropped from the labels right away if it's looking bad!

8. A font picker of some sort would be great. I think it would be great to keep as many people on system fonts as possible, to keep the weight down, but offer the option of other choices with better language support?

This probably leads to the point of overhauling theming and settings in general. To make this work for as many as possible, we need to over far more control over each element of the design.

Settings need to be stored in a new IDB table, and act in more of a global sense than they do now, so it's probably worth getting Unistore involved for some global state goodness.

9. Agreed, this'll need some thought and planning

10. Oooh, that's a very interesting (and daunting) idea! Would we then need to look at encrypting the data somehow? And how/would we do resets? This sounds like a big task, but could be brilliant.

11. Nice! Again, could be a reasonable task.

--

The great and awful thing about JournalBook, is not having the actual entries on a server. It means any data migration has to be done on app boot, and it's mega scary to do! So any task that requires migrations will need to be handled very sensitively.

A friend suggested crowdfunding and I thought it was a bit much at the time, but that's really interesting you've suggested it.

--

Here's a couple of other suggestions that popped into my head whilst responding:

12. More transparent tracking, I'd like to make it clearer what's being tracked and emphasise that it's all anonymous. I do feel it's important to know if people are actually using the product, so removing everything is probably over the top, but it would be good to open it up a little more.

13. User feedback - would a means of user feedback/voting for features be worth investigating. It's probably a little soon to be doing this, so maybe a more visible in-app roadmap/changelog would be a good start.

[jsvde]

Regarding 4.

I'm currently working on a small wrapper around @octokit/rest.
Since GitHub provides unlimited private repos for free users as well, why not use GitHub as OAuth provider, create a private repo and simply push the exported json structure to said repo?
When a user logs in from a different device one could select the previously created repo and import the blob. This would work with the current import and export functions with only minimal changes.

I just did a little proof of concept and it works pretty fine to be honest.

If you're interested I'll turn my POC into a module, setup JournalBook and create a PR :)
Only prerequisite would be that you create a GitHub Application and setup
github-secret-keeper on heroku or something like that.

Let me know, if your interested!

[AlvaroR156]

Hi,
I will also add:
12. Option to re-order the questions.
Thanks for the app, it works really well.

[trys]

@AlvaroR156 absolutely, it's on the backlog: https://github.com/trys/JournalBook/projects/1#card-16039530

@jsvde that sounds super interesting - my only comment would be, I don't think GitHub can be the only storage provider. The majority of current users are no-doubt developers, but I'd like to think this will expand beyond that group in time. Maybe GitHub is a starting point for now, and we look at adding Google/Dropbox/Other providers in the future.

[jsvde]

@trys totally agree. I just implemented a storage class with multiple adapters (default: file). Got github and dropbox working. Will do a PR when google drive works as well.

[MHM5000]

The one thing that I'm really concerned about is how much can we store in the browser?

1. Language settings could be in the URL path or the user's cookies.

2. Here's the thing about calendars: I'm born on May 21st, 1993. Since in Gregorian calendar, the leap day is added at the end of the second month of the year (February) and the year starts on the 11th day of winter instead of the beginning of spring, I can't rely on the information my calendar app provides me. [just imagine if someone is born on a leap day/leap year]. Also the order of months: In Shamsi calendar, we have 6 months with the length of 31 days and then 5 months with the length of 30 days. The last month is either 29 or 30. But in the Gregorian calendar, I don't see any pattern. Now, let's throw in a lunar based calendar: Hijri Calendar! It's no longer 365 days! It's 354/355. Some countries like Iran rely their lunar calendar mostly based on observation.

   What I'm trying to say is: Stay away from datetime converting functions! Most of them are inaccurate.
   First add the capability of having multiple journals, then add each calendar and let the user choose if they want a specific calendar; obviously.

3. Both a stopwatch and a timer could come in handy. Also a combination of both! A timer that can have negative values with color red on top it. But we probably should only implement one of them. I think we should have a vote on this.

4. Apparently @jsvde is working on syncing. That's going to be amazing. Thanks man!

5. It's best practice to use a tool that gets updated more often than the others. Don't use dead projects. And also don't forget about contenteditable and Medium.com editors like Medium-draft.

6. Let's create a feedback form in typeform and show it's link in the corner of website. One of the questions could be if current users want todo list added to JournalBook and if os, do they want it complex or a simple version is good enough? Based on the answers we can decide on when and how of implementing different parts.

7. Thanks!

8. I can say with confidence that if you want to attract any Middle Easterns, the site needs a better typography. Maybe we can live without translations, but bad typography hurts the eyes and lowers the UX and all together creates abandonments. Right now I don't know how many of us are using this app in our native languages, but if you want to expand Journal Book (or any other products in the future) in this regoin you need to thinnk about theses things.

9. Of course.

10. Since everything happens in JS and is client-sided, encryption absolutely needs to be password + 2FA of some sort. Maybe with Google Authenticator? I think Google Authenticator is the only offline version possible.

11. Of course migrations are difficult, but they are not impossible.

12. Make it an option in settings with 3 options: Google Analytics / Monthly Typeform popups (that the app looks for a raw github link every month / None.

13. Typeform or some other system could help amazingly.

14. Re-ordering questions is a must.

[jsvde]

Just a little update regarding import/export: I’m currently on vacation till the end of the week so expect a PR next week. Sorry for the delay thought I could get a first PR out before this week. How about tracking the state of syncing and related ideas in a separate issue? GitHub Sync will be delayed since it’s the only adapter that requires a dedicated server/backend. Initial version will include file, Dropbox and google drive. See #42

…

Am 19.01.2019 um 05:57 schrieb Mohammad Hossein Mojtahedi ***@***.***>: The one thing that I'm really concerned about is how much can we store in the browser? Language settings could be in the URL path or the user's cookies. Here's the thing about calendars: I'm born on May 21st, 1993. Since in Gregorian calendar, the leap day is added at the end of the second month of the year (February) and the year starts on the 11th day of winter instead of the beginning of spring, I can't rely on the information my calendar app provides me. [just imagine if someone is born on a leap day/leap year]. Also the order of months: In Shamsi calendar, we have 6 months with the length of 31 days and then 5 months with the length of 30 days. The last month is either 29 or 30. But in the Gregorian calendar, I don't see any pattern. Now, let's throw in a lunar based calendar: Hijri Calendar! It's no longer 365 days! It's 354/355. Some countries like Iran rely their lunar calendar mostly based on observation. What I'm trying to say is: Stay away from datetime converting functions! Most of them are inaccurate. First add the capability of having multiple journals, then add each calendar and let the user choose if they want a specific calendar; obviously. Both a stopwatch and a timer could come in handy. Also a combination of both! A timer that can have negative values with color red on top it. But we probably should only implement one of them. I think we should have a vote on this. Apparently @jsvde is working on syncing. That's going to be amazing. Thanks man! It's best practice to use a tool that gets updated more often than the others. Don't use dead projects. And also don't forget about contenteditable and Medium.com editors like Medium-draft. Let's create a feedback form in typeform and show it's link in the corner of website. One of the questions could be if current users want todo list added to JournalBook and if os, do they want it complex or a simple version is good enough? Based on the answers we can decide on when and how of implementing different parts. Thanks! I can say with confidence that if you want to attract any Middle Easterns, the site needs a better typography. Maybe we can live without translations, but bad typography hurts the eyes and lowers the UX and all together creates abandonments. Right now I don't know how many of us are using this app in our native languages, but if you want to expand Journal Book (or any other products in the future) in this regoin you need to thinnk about theses things. Of course. Since everything happens in JS and is client-sided, encryption absolutely needs to be password + 2FA of some sort. Maybe with Google Authenticator? I think Google Authenticator is the only offline version possible. Of course migrations are difficult, but they are not impossible. Make it an option in settings with 3 options: Google Analytics / Monthly Typeform popups (that the app looks for a raw github link every month / None. Typeform or some other system could help amazingly. Re-ordering questions is a must. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.