Great idea, especially since many popular cycle tracking apps have a bad rep of sharing data eagerly with Facebook and other entities.
One thing though: I know it's popular in these apps to show the cycle as a "clock face", but if you think about it, this is a weird representation, because of the variations in cycle lengths (of natural cycles not changed by contraceptive hormones). So, if one cycle is 26 days long and the next cycle is going to be 30 days long, the clock face will show an average of 26 days for the next cycle and the handle looks stuck "5 minutes before 12" and every day, the handle doesn't tick one further, but the unit (day) becomes more compressed.
This makes comparing cycles unintuitive and suggests that natural cycles always have the same length. In reality, the majority of women have fluctuations of 8 days or more in their cycle's lengths per year.
> many popular cycle tracking apps have a bad rep of sharing data eagerly with Facebook and other entities
Many no longer have a choice as to whether to turn their data over to law enforcement who may use it to deny lifesaving medical care. (Florida briefly tried to make reporting periods mandatory for student athletes, too, but that fortunately failed)
In my opinion if you're running something like this in a location where you might be forced to share the data for such malicious purposes with law enforcement then it should be your responsibility to (re-)design the app to provide users with a local-only option for data such that there's then nothing personal on the servers to be requested by law enforcement.
> Florida briefly tried to make reporting periods mandatory for student athletes, too, but that fortunately failed
Your wording is false. Florida is a state and the state never did this. The reporting is already on the form, but is optional. Some private industries wanted to make it mandatory, but the gov has no control over this.
Cycle makes a ton of sense to me, because it is a cycle.
The issue of lack of exact ability to predict will be an issue no matter what, because the whole point of this app is to help you predict when your next period will start. It doesn't matter if that's displayed as a countdown, or as a calendar, or what.
But perhaps one way to alleviate the "5 minutes to midnight" issue is to have the entire section between, say, 9 and 12 be the potential start of the period, with a less-certain color at the start and a more certain color by 12. For people with a lazier period, the "maybe it will start here" section could be wider, and for people who are super regular it could just clearly show it starting at 12.
For comparing between cycles, it looks like there's a very clear statistics tab with that info.
Yeah - you are right. But I like it that I can see how many days are left - even if it's not 100% correct and I get stuck at "5 minutes before 12" because then I see that it can appear every time.
Maybe I'll add an option for another representation... something like the commit graph in github (don't know the name...) That would be nice too.
To compare the cycle length there is an extra statistic section. I want to add a graph there to make the fluctuations more clear.
Do you mean the contributions-in-the-last-year block at the bottom of your user profile? I can see that being a good alternative to the monthly clockface, because it's broken out by weeks and not months. Color intensity might be useful when you get around to tracking things like mood.
I dumped all note-taking tools and just use Sublime. I took the idea of timestamp-based ids from Zettelkasten and simplified it even more. My setup now is:
Create text file named `YYYY-MM-DD Title of the Note.txt`. Save to a folder. Write freeform.
I think it's important to understand one concept of note-taking:
You can either spend more time organizing to spend less time retrieving information later. Or you can spend less time organizing and (slightly) more time retrieving information.
If you're starting out or don't refer to older notes that often, it's a better idea to just dump everything with as little friction as possible and use a search tool to find information.
This is basically org journal. With a quick search you can find everything you need. I agree the tagging aspect and organization is overkill for many purposes, but the benefits is that it might help you remember related topics that a search would not have turned up.
Well, the actual file size is what is going to be parsed and run on my computer. <something ... something.. google...google..parse sizes for javascript etc.>
Same here, except I had someone make native apps. They were bad and unmaintained for a long time (solo dev here as well, running a small business). But still, people used this Android app that didn't receive updates for 4 years(!) over a mobile website where I put a lot of effort into.
At some point, I gave up. If apps is what people want, I make apps. After a looong process of deciding between native and hybrid (build with Ionic), I finally settled on Ionic. The result is actually quite okay. People love it. I can maintain two platforms with a single code base and will probably rewrite parts of the web app with Node so that I can share core code between 3 platforms.
How all of this will turn out in the long run, I don't know. Maybe I'll outsource app development at some point again in the future, now that I have a working product that is exactly as I want it to be.
Seriously, consider releasing a Cordova-based app. Slap some functionality on top so that it won't be rejected by Apple (Website-only wrappers aren't allowed). Maybe an offline storage or whatnot. This shouldn't take too much effort and you might be surprised that new customers find their way to your business.
I want PWAs to succeed, because I would love to publish close-to-native apps without an app store. I think PWAs are a great thing for the open web. However, hyping PWAs with unrealistic expectations doesn't do any good. The Ionic team talks in the same vein. I like Ionic, I don't like hype. Here are a few reasons why PWAs aren't there yet and probably won't replace most apps in the near future:
- No native APIs. Yeah sure, you can order a coffee at Starbucks, but the underyling hardware isn't exposed to JS. You won't be able to make a camera app with PWAs.
- Input controls suck. Same as with every mobile browser and every Cordova-based app: You cannot control how the keyboard behaves and I suspect that it's not even in Apple's interest to make Mobile Safari super-great. Sure, they're working on PWAs, but that doesn't mean anything. Just see how bad Mobile Safari's <select> looks like. Or bugs in multi-selects that have been there forever.
- They still run in a browser. It shows an address bar and whatever else your browser is always showing. Try Twitter's PWA right now: https://lite.twitter.com It's way too easy to accidentally swipe back. And then, Twitter being a shitty Single-Page-App, the browser loses its scroll position.
- PWAs suffer from the same problems like all SPAs [1]
And finally:
- A PWA is just a proxy to download and cache responses from a server. It enables offline support (kinda) for single-page apps. It's not a magical something. The problem is that most users go to the App or Play Store first (like djrogers pointed out here: https://news.ycombinator.com/item?id=15219682). They COULD be using PWAs – or at least good mobile webistes – right now, but they aren't.
I think PWAs will find their places and I'm betting on them, too, to a certain extend. But over-hyping PWAs without addressing these issues is just naive.
> - They still run in a browser. It shows an address bar and whatever else your browser is always showing. Try Twitter's PWA right now: https://lite.twitter.com It's way too easy to accidentally swipe back. And then, Twitter being a shitty Single-Page-App, the browser loses its scroll position.
Android doesn't show the address bar. I don't have iOS but it seems like Safari support for PWA isn't as far along as Chrome.
One mobile safari bug that really irritates me is not being able to move the cursor on a text input element. Basically, if the text in there is longer than the element, you won't be able to move the cursor left or right. You can only work with the visible part of the input element. Try it - it's really quite terrible!
I know. Same with textareas, especially if they're wrapped in some kind of scrollable container. It is a mess. I don't know why it's not being fixed.
The only reason I can think of is that Apple intentionally keeps the mobile experience slightly crappy so that people perceive native apps having higher quality.
Of all companies, Apple should be the one with the best usability in a browser, no? But hardly so.
You can still have 95% common code with shims to fit the different platforms. Oddly enough, the original Doom is one of the best examples of this process in action. It supports Windows, Linux, and a host of other OS targets, at a time the interfaces couldn't have been more different.
Because I've written the game in JavaScript and it renders to Canvas. It also works in the browser. To go native, I'd have to rewrite everything from scratch. And then I have to maintain 3 platforms.
Maybe Unity is the solution, but right now, it's not written with Unity.
Why? App Store exposure, client-side demand for an app, offline-first – and quite frankly, because it's written for desktops in mind and the mobile experience just sucks. Wrapping it in Cordova at least gives some control over the experience, such as: You can't accidentally swipe back on the browser, full screen, no address bar etc.
Check out the Twitter PWA (https://mobile.twitter.com). Accidentally swiping back happens to me a couple times per day.
How is writing an entirely new view layer for every platform more maintainable than a few if-else trees? React Native doesn't come with good support for both platforms out of the box. Many components are unstyled. You still need to match the platforms' native behavior. TabBar is shit on iOS, you better go with TabBarIOS, and suddenly, you have exactly the same mess like in Cordova-based apps.
The benefit of Ionic 2 is that there's hardly anything you have to do yourself to target the OS / device. It's all handled by Ionic.
One thing though: I know it's popular in these apps to show the cycle as a "clock face", but if you think about it, this is a weird representation, because of the variations in cycle lengths (of natural cycles not changed by contraceptive hormones). So, if one cycle is 26 days long and the next cycle is going to be 30 days long, the clock face will show an average of 26 days for the next cycle and the handle looks stuck "5 minutes before 12" and every day, the handle doesn't tick one further, but the unit (day) becomes more compressed.
This makes comparing cycles unintuitive and suggests that natural cycles always have the same length. In reality, the majority of women have fluctuations of 8 days or more in their cycle's lengths per year.