Pre 6.0

Legacy MyInfo versions topics and topics that are no longer relevant
Locked
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Pre 6.0

Post by Fred »

With these "little things" done (hopefully) in 5.7 beta (or 5.75, to exterminate remaining bugs), marketing considerations will prevail since 6.0 will have to be prepared, and first, 5.7 beta will have to be split up between Standard and Prof. - perhaps you can offer an in-between "Standard 5 to Prof. 6 Prepaid" upgrade, so that people who don't have 5 Prof. (as I have) can stay with the goodies of 5.7 beta IF they are willing to buy version 6 beforehand, at an intermediate price but without having to upgrade AND to update in a row; as said before, in order to finance development of 6 AND to have some of its goodies as soon as they are developed, and in view of the fact that those goodies need user feedback even during development (= since we're going to create something new, not available in any software out there), again my proposal to discuss those new features and get to some basic understanding on them, and then have people PRE-BUY version 6, in order to have delivered to them those developments before general release.
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

Thus, towards a 6.0 "subscription", it appears undeniable that first and foremost, an array always to be loaded with MI is necessary, and which would be checked and updated for every single renaming, deleting and shifting of any item anywhere; it would be a general, rather big array for many functions at the same time, so all of MI's functions depending on updating would access it, renaming, deleting, shifting, of course, but also favorites, tags, filters, and the zero tree / super tree of course; any super tree without such an array being created first, would only enhance chaos in your topics' / items' handling, not create anything outstanding towards MI becoming an outstanding program in a class of its own.

I know this is real work, and I know that for optimizing the super tree's precise functioning then, we'll need intrmediate results, but then, ALL MI 6.1 needs to be in a class of its own, will indeed be this, and only this, being done... but being done in a perfect way; of course, I include in this feature all ways of inter-topic references, to topics, to items (and perhaps, but not necessarily so, to paragraphs within items), and in trees, that is (and perhaps also in texts; and updating would be mandatory on the topic, and on the item levels, but not necessarily on the paragraph level also, i.e. if you shift a paragraph, perhaps checking / processing this in the array and the functions depending on it, would perhaps to be done in a later version, it'd be simply too much programming effort in a first step I fear - but this relative lack of precision in a first step of the realization process would seem perfectly acceptable to me and to many).

Of course, this makes me remember askSam 6.1, with its tremendous novelty, its tree-on-the-fly, from which all things would have been possible if AS's management had been able to get rid of AS's multitude of serious bugs; as we all know, they weren't.

And let's remember, Petko and all "software professionals" here (Felix, that's you, and others maybe), that this real work I'm asking for, is INTER-COMPONENTS: It will not be "better", "more modern" components that will do this work, but it'll be YOUR PROGRAMMING WORK, accessing those (current or future) components that'll make the difference between MI and every other competing program!

Even before 6.0 or 6.1, let's hide the "dated" character of some of the components, as best as we can, but with that tremendous super functionality in 6.0 / 6.1, hordes of new customers will come here even if it will not be possible, up to then, to hide the "dated" character of SOME of those components... FROM then ON, there'll be plenty of money to replace those components with state-of-the-art ones.

This being said, MI cannot stay, up to then, in its current GUI, but it doesn't need to stay this way, either, cf. my lengthy post in my thread "On 5.6".

E.g., the tree won't be as ugly as it is at this moment as soon as you hide its ugly elements, as prescribed there. The toolbars, in their regular form, are quite modern, nothing needs to be hidden there; it's only in their alternative form that they get ugly = outdated, e.g. the favorites toolbar when you have it in list form. Thus, instead of this alternative list form of the favorites' toolbar, a list FIELD for the favorites could do... if it's really necessary (= which I doubt) to that much concentrate on favorites, once we get a much better system than just favorites.

Similar with the search results pane: It's not beautiful as it is, but it's bearable, and within another colored (= white) GUI, and with white (= invisible) borders, it could be greatly enhanced, in the waiting for much better things.

A lot of MI's GUI's elements CAN be enhanced even now, AND SHOULD BE, in order to not put off new customers coming to MI for its 6.0 / 6.1 features, and that some elements cannot be embellished up to then, should NOT be a pretext for not doing the max for all elements that CAN be embellished (and be it by hiding them / hiding their borders / hiding them and retaking their core elements within new, superposed elements, that ain't "necessary" but show those elements, hidden elsewhere, in a more pretty way, cf. again my considerations in the "On 5.6" thread - all this CAN be done, and SHOULD be done!).

This way, MI 7 will not share the fate of AS 7 but will lead the premier league.
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

Petko, I edited the second paragraph of my post above, hence please reload if the first and automatic loading up into your system got my post without this edit yet.
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

A minor thing that should be amended for v.6, is the cloning feature. Not yet cloning inter-topics, nor updating sub-items of clones, just like it is for now, but DOING the cloning should be, as said before, much more easy, cf. my posts on this subjects. Thus, make a key-assignable command "Clone this item" and, "Insert cloned item after this item". That should be more than easy and would not put off any more prospective buyers discovering cloning and then discovering that cloning is almost rendered impossible for practical use, up to now. (And many of us current users, me included, are indeed WAITING for a practical clone feature, even knowing its current limits will subsist for some time.)
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

wsp has had almost one year (and will have more years) of iPad usage now, so nothing (anymore) against his having bought it (= at time = early adopting that is), but there are people here, in West Europa, who buy the iPad (1) now, in February 2011, at almost full price: oh my God!

Some days ago - unfortunately, I didn't store the address - I read another user review of somebody having tried to use Win 7 on a slate. He had bought (and then returned) the slate in order to continue to use his current Win programs there (as we're all hoping for MI one day - again, I'd like to do it with a stylus, in front of customers / prospective customers), and instead of being able to put in his commands in an ergonomically acceptable way, he was forced to put in a lot of otherwise unnecessary commands, including launching (and then hiding again) a virtual keyboard taking 2/3 of the screen, and so on... He blames Win 7 for all this, of course.

So stop now. Every single PROGRAM has to create new mouse / stylus shortcuts in order to become slate-compatible, AND they have to be logic / mnemonic / intelligent in the sense that they are presented in an intelligent way, depending on context; with regards to a program as MI, that means, e.g., that the slate GUI must take into account that there will be a lot of reading, and hence, a lot of navigating (and searching, and of recalling of pre-figured SETS of info clusters), and even - did this occur to you, casual reader, before my mentioning it? -, a lot of referencing / standardized annotating for further processing, but only SOME notetaking.

But then, all this is EASY!

It's not really difficult to implement such slate functionality, since all functions remains the same, it's just that their TRIGGERS must intelligently deployed, depending on context, onto some "fields" within the sensible surface of the screen.

But then, most developers ain't not even smart enough to see that those command fields should be placed on the right and bottom borders of the screen... nor that they should be placeable, by option, to the left and bottom borders of the screen, for left-handers.

For example, it's impossible to develop just for stylus screens now, since 99 p.c. of slate comps (= of acceptable prices, that is) won't have any. Thus, you always must take into account that people using a stylus will place their ball of the thumb on the screen, and the unwanted effects of this, if you don't do it in a way they can do without such a nuisance. In an outliner, it's impossible to navigate just by your fingers only (since, again, your lists must not be blown to where they wouldn't have but 10 or 12 entries left), and this DECIDES upon the positioniong of lists - MI's tree - to the right border of the screen, e.g., in slate mode...

So, where did you see such an option: nowhwere? You see? It's a bunch of idiots, out there, and that makes Job's fortune.

Or the other way round: I'm able to advise Petko with his slate GUI, with regards to 6.0 / 6.1, sufficiently, even if he decides on transposing MI onto Windows slates.

Thus, no need to defect to lesser programs in order to get some outlining on a slate, an iPad platform, for example.
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

BTW, on a slate, my ways of having the command triggered by a stylus (or a finger) depending on the POSITION of the stylus / finger (as was my mouseclick, back in 1998) in the line of the list, will be of ENORMOUS usage, since slates / fingers lack those 7 mouse keys I consider the strict minimum for commanding non-slate comps. Thus, depending on the position, in width area, of your (stylus or finger) tap in lists and other screen elements, MI will launch different commands. A more natural working environment than MI with my position-dependant tap encoding will simply not be possible. (And since it's a known formula henceforth, no cynics like Jobs et al would be able to "patent" it for their delusionary, totalitarian enterprises.)
Locked