I think that you have to keep an eye on what differentiates MLO from other products. For me, these are: 1. It runs locally, and therefore I hit no work firewall related issues. 2. It is really fast and really stable. Comparing it to a webapp - there are fast web apps, and they get faster every day, so agreed, this differentiator is getting weaker, but MLO screams by comparison to anything I have seen, and it never crashes, never loses track of which button you pressed, never fails to submit a change. A webapp would be a downgrade. 3. The Rapid text entry works really well and is very handy.
I am not sure the architecture you advocate would keep these advantages. I see some real advantages to the approach you suggest, but if that is what I wanted, I would use Remember the Milk. Presumably you could maintain the RTE parsing, but speed would suffer and reliability , and I would be constantly frustrated by firewalls. I think the priorities should be: 1. Improve the collection features on the portable platforms - put the RTE parsing into the iphone, android and BB versions. 2. Automate the syncing, This to me is the most disappointing aspect of the current tool. A simple thing, but a big nuisance. 3. Improve the UI, which is fairly primitive. I am sure that is why it is fast and stable, but a few changes could be - 1. some sort of a widget to show you your todo list at a glance. 2. views on tabs that can be moved about like the tabs in chrome - so you can arrange your todo list on a second monitor or something like that. 3. Allow hiding, or splitting of views -so you can have project 1 in one window, day to day todos in another, checklists in a third. 4. If the cloud-o-philes insist, maybe a simple web front end so you can collect or check off items on a webpage - but then really, why would we use MLO if this was the direction they put the development $$. RTM works. The power of MLO is the big, smart, fast desktop client. Okay, now everyone can start telling me how the desktop is being made obsolete. Before you do however, here is my rebuttal . The desktop is not being replaced by tablets and phones, tablets and phones are morphiing into tiny desktops. Someday soon, MLO Desktop will work on your phone as it is now, fully functional, and you will drop it into a cradle when you get to work to see and use a full desktop. If I went back five years in time and showed you a Galaxy note II , you would tell me that day had already arrived. If you really want to ride the convergence wave, port the full power of the MLO desktop to iOS and Android, just in case Windows 8 and Windows Phone tank (and, if there is justice, blackberry 10, but I doubt it. Goodbye blackberry, say hello to palm for me). Now as for Mac.... Not even Apple thinks that OSX has a future. They are trying to ride iOS into the future to give it life, which given its limitations compared to Android, is ... well ... I suppose it could succeed. VHS beat Beta, so anything is possible... but Android is over 30% market share and growing fast and iOS still cannot present a wireless file share or properly multitask, and it is almost 2013. Surely someday the market will notice iOS has pretty graphics, great gestures, and all the power of Windows 3.1. On Monday, 10 December 2012 16:58:58 UTC-5, natG wrote: > > Mark, I was about to start a new thread on MLO re-design for some time now > and your post has finally prompted me to do so. > Besides Mac/Linux problem, many other problems would be bypassed as well > with the following proposal. > > In short: > 1. The ingenious rules engine (and database) should > be completely decoupled from the GUI and reside on an Application Server. > 2. Andrey should create an API that allows access to the DB and RE > (RE=Rules Engine). It is OK to keep this API private just for the MLO team. > As time goes along, MLO can decide what functionality to expose to other > developers or end users. (Remember The Milk does this.) > 3. The front end gui needs very little brains. Basically gets the status > from the RE server. > 4. Besides other benefits, this approach would ELIMINATE the need to sync > since all guis are reading back end data -live-. > 5. MLO pricing can be adjusted to the new model which hopefully would make > everyone happier. > > Now, let me extrapolate a bit. > 1. Andrey knows Java. Port the rules (sans gui) to Java. (If not yet in > Java.) Deploy RE (and DB) on Java App server. *Calls to the App Server > can be in any language via SOAP or XML. * > 1b. This would allow deployment to any cloud and gain all those benefits. > 1c. All of a sudden we have project collaboration in MLO. > > 2-3. Build gui's in *any language* *AND platform* you like. Many > programmers can work on different gui's at the same time. Much LESS work > required since all the brains need not be rewritten. Open up limited parts > of the API to anyone. How about an open source gui project? > 2-3b. An HTML5 gui (now possible due to App server) would solve all cross > platform problems, just like that<snap fingers>. > 2-3c. Andrey can focus on the rules and db engine(s) to make it even > smarter (possible?), better, faster, whatever. (Of course Andrey reserves > the right to write a gui:) ) > 2-3d. Multiple types of gui's can be built. You can have a mini gui, a > maxi gui, or whatever gui you wish. Simple stuff. > 2-3e. You can have a Java gui which is multi platform automatically, > > 4. Now, the Android version, which is currently crippled, can utilize all > the benefits of the desktop version. (Because the rules run on the RE > server.) > 4b. Sync? What is that? Oh, if you are off line. Ok, for those situations > we have sync, using existing technologies. In today's world however, 99% of > MLO is used while online anyhow. No sync necessary. Major > headache eliminated. More time for other goodies. > 5. New pricing scheme with many new possibilities. > 6. Doable in much shorter period of time. > > I have much more to say about this but need to go now. > > nat > member of MLO_BETA. > > > > On Tue, Dec 4, 2012 at 4:23 PM, Mark Levison <[email protected]<javascript:> > > wrote: > >> There are frequently requests to create MLO for Mac. Let me help you >> understand how complex this would be and why I hope Andrey never does it. >> >> MLO Windows is written in Delphi (aka Object Pascal - >> http://en.wikipedia.org/wiki/Object_Pascal) - the Borland Version >> (presumably Embarcadero now). While it turns out that you can compile >> Delphi for the Mac that doesn't mean it would easy (or sensible to port). >> >> Fundamentally a program like MLO is made from 4-5 parts >> - GUI - which involves working with the windowing system >> - Rules Engine - handles the tasks themselves and all of the rules MLO >> this the real power of the application >> - Synchronization Engine - the bit that speaks to the internet, wifi etc >> - File System - the bit that saves MLO files, archives etc. >> - Extraneous bits - talk to Outlook etc >> >> When trying to port to a Mac (or Linux) we have to ask what would come >> over for free (or with little pain): Rules Engine and Synchronization >> Engine are the only parts that are likely compatible out of the box. >> >> The Mac file system is a bit different than Windows (.DStore, storage of >> preferences, etc.) that would take a fair amount of work to port. However >> that's not the hard part. The kicker is the GUI - the Mac windowing system >> is very very different - it would be a complete rewrite from scratch. >> Finally I just can't imagine the pain in trying to figure out how to port >> Outlook sync etc. >> >> So its simple MLO **might** recompile on a Mac but we're talking several >> years for team to build a GUI that is anywhere near close to Windows - is >> that where we want Andrey and his merry band to spend their time? If it is >> are you personally prepared to fund 2-3 person years of work - I'm not. >> >> Or would you rather that Andrey created a better Windows product, IPad >> (Objective C)/IPhone (Objective C)/Android(Java) >> >> Yes there are other strategies but they all have the same basic problems. >> >> FYI This assumes a simple MLO architecture clear separation of concerns >> etc. In addition Andrey has never told me anything about the architecture >> or anything else - I'm just working off of comments made on list over the >> years. >> >> If you really think that a Mac product matters then help create a >> Kickstarter project to fund its development. >> >> Off to help some people understand Scrum ( >> http://agilepainrelief.com/notesfromatooluser/2012/11/learning-scrum-through-games-golidocks-iteration-ii.html >> ) >> >> Cheers >> Mark Levison >> Agile Pain Relief Consulting<http://agilepainrelief.com/notesfromatooluser>| >> Writing <http://agilepainrelief.com/notesfromatooluser/> >> Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov >> 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>26 and >> Montreal <http://agilemontreal.ca/agile-tour-2012/> 24 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "MyLifeOrganized" group. >> To post to this group, send email to [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/mylifeorganized?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To view this discussion on the web visit https://groups.google.com/d/msg/mylifeorganized/-/GSEdVvpN1PwJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
