Isn't this simply the cornerstone of functional testing?
At that level your tests should be executing business test cases. If a functional test fails there is either a corresponding unit test failure or the failure of the interaction between the methods rolled up into the business logic (functional test).
Functional testing is related, but it's not really the point of the article. In the context of the article, functional testing is actually one logical step above his Interactor—the functional test would end up effectively testing the interactor code (which includes all the model, etc code) plus the controller code to make sure the session is properly set (i.e. now that I'm logged in, was I properly redirected?). The latter is outside the context of the "business logic" of logging the user in.
The point of the article is in organizing the business logic of use cases into their own objects—"business logic" being defined, presumably, as anything non-web and non-persistence related. This is done in order to avoid the spaghetti that real world "thick model" applications tend to accrue; or similarly the spaghetti that some developers leave in controllers.
There have been a spate of articles on this topic in recent years. Service objects, interactors, DCI, etc, etc. One or more of them is probably good advice for large projects. :)
Agreed. I'd like to know the numbers on how much users are willing to pay for an application such as this. Having this metrics helps to determine the quantity/size of features in the application.
Example, enterprise applications are loaded with features and have a much higher price point. On the other side, there are may free applications out there that are much more lightweight.
Which market you choose to target helps determine the price point. That price point will drive the selection of features that go into the product.
Is your goal to run this as a business? If it is you're asking the wrong question.
"What kind of note taking software would you build?" is a question a developer/engineer asks.
When you put your business hat on you need to start asking questions such as "What kid of note taking software would you pay for?" & "How much would you pay for note taking software that does X?"
If your goal is a business & not a hobby (which I assume it is since most people don't borrow 50k for a hobby) you need start asking questions related to generating revenue. You can build the best note taking software ever but if no one is willing to pay for it it will not be a profitable business.
This is great insight, thanks. To my surprise, some of the open-ended survey feedback has been "if you do x, I would be willing to pay" but it did not occur to me to include specific questions ie- what they would pay for and how much. This kind of tone; these revenue related questions will make for a great follow up.
Fortunately (or unfortunately) the reason these pop-overs are still used is because they still work.
Users are much more likely to perform an action (ex. subscribe to a mailing list) when it is presented to them in a pop-over. (At least that is what my experiences have been)
If you hate them or not, they do work and until the numbers prove otherwise site owners will continue to use them. The decision purely comes down to the best way to increase key metrics.
In full disclosure - I am the founder of http://RateMyStartup.com - The site lists new starts (and uses pop-overs). I would recommend checking out Nevahold.com directly to give it a chance. It really is a cool concept for a startup.
Exactly. If you're in an entirely new space (e.g., Twitter when they first launched) -- an MVP should be the minimum thing that proves the functionality, e.g., distributing your status to friends via SMS.
If you were trying to launch a Twitter competitor now, you'd be hard-pressed to get away with the same degree of minimalness.
However, if you had a unique take on the approach, say, all Tweets get posted backwards and upside down, then you can probably get away with a page that does that, as minimally as possible, to test and see if people actually like that. If they do, then you start fleshing it out. If everybody hates it, move on to the next idea, or pivot it into something better.
The point is that the MVP allows you to qualify whether or not people will use it. If you're solving somebody's pain, they probably don't give a flying hoot if it has fancy mouseovers, or a WebGL rotating background, or even good typography. Do those things help? Sure. But if the idea at its core is rotten, then all those things are is a waste of time. They are things that slow you down from figuring out whether or not the core of your idea has validity.
If the idea is proven, by somebody else entering the market first, then the bar is raised on what gets counted as 'minimum', unless you're approaching the problem in a uniquely different way. Google Drive is, as near as I can tell, a feature-for-feature knockoff of Dropbox. That said, it couldn't be crappy. The Google Docs integration isn't enough of a differentiator to allow for the bad initial first impression of a half-assed client. If it worked in some fundamentally different way though, perhaps it could have.
The point though, is exactly what you said... MVPs are contextual, and the context is the market. How unique is the idea. Is it radical thinking? Does the model need proven? If nobody's done anything like it before, why not? Is it a great idea that you're the first to stumble onto, or is it a bad idea that everybody else has realized stunk, and haven't done it for that reason. Get your product out there to find out, as quickly as possible.
tl;dr - The better solution is probably no public loans or grants whatsoever.