you're putting the cart before the horse. frameworks are not written, they're grown. see Evolving Frameworks from Ralph Johnson, one of the Gang of Four.
edit
I do not understand, what the author means with "application", does this
mean raw-coded-project or does this mean project with basic functionality
which will be taken to the later framework.
Either, depending on your expertise in programming and the problem domain.
It's the goal (a useful framework) that's important, the process should simply support you
in achieving it as best as possible. You may either start slow, develop three applications in the same problem domain without any code sharing among them,
and just look at the code bases and see what they have in common, and possibly refactor these three finished applications to converge the code, and extract the common pieces.
This won't give you any boost during the development of the second and third application,
but neither will it hinder their development with concurrent refactoring of the previous ones.
Let's say you want a framework to ease writing browser-based, turn-based
strategies.
Your first turn is to write such a game without thoughts of reusing the
code outside this single game, but with attention to code reuse within
it: refactor mercilessly, apply all the principles of programming: OCP,
SRP, DRY, etc. Especially DRY. Code reuse (Don't Repeat Yourself) is a
basic principle of programming, and the first step on the path to a
framework. You will end up with a library of classes and/or functions
that are used across the game.
Your second turn is to write, adhering to the principles mentioned above,
another browser-based, turn-based strategy, using the code of the first
game. You'll find that much of it is specific to that first game. Use
the pieces that fit in the second one without modification, refactor those
that are useful but don't quite fit so that they are useful and do fit
in both games.
Repeat the procedure with the third game.
Three is the smallest number that gives you any hope of arriving at code
that is truly reusable across the problem domain (think triangulation),
not a guarrantee that it'll happen. OTOH, deriving a useful framework
without the support of real-world applications is a sure way to end with a
pile of useless crap.
Johnson:
Developing reusable frameworks cannot occur by simply setting down and
thinking about the problem domain. No one has the insight to come up
with the proper abstractions.
Read the "Three Examples" section carefully.