Strategy and architecture-wise...

As a developer, you would want to write each piece of (core) code that does 
something useful *once*, and in a way where it would be able to run either 
as part of a desktop execution model or a cloud service model.
So the core services that are part of MLO would need to run under Windows, 
Mac, Linux, (and also on a web server of a preferred platform) and be 
called from a UI layer on those platforms, and also be called from a UI 
layer on mobile, cloud-connected devices.  Granted, this is an 
oversimplification, but humor me for the sake of discussion.

So there would be a "Core MLO" development team, and then separate UI 
development teams for each platform, e.g., Windows, Mac/OSX, Android, iOS, 
WinMetro/WinPhone 8, Linux, and the biggest platform of all... *Web*.

Interestingly, one of the current products that would make much of this 
possible is... (drum roll...)
Delphi!  Delphi XE5, that is.  Read about it here: 
http://www.embarcadero.com/products/delphi

However, possibly a better bet, toolset-wise, would be the Mono/.NET stack, 
and the related tools for MonoDroid (Android), MonoMac (OSX), MonoTouch 
(iOS), all of which primarily use an open source implementation of the 
C#/.NET development stack.  Oh yes, and the chief architect of C# is also a 
chief architect of...  Delphi! (Anders Hejlsberg is the guy's name)

And all this is not to dismiss Java toolset, of course, especially since 
Android is essentially based on Java.

With the right toolset and architecture, MLO could be available on all 
major platforms.  I would hope that support for Blackberry and Windows 
Mobile versions would be discontinued and those resources dedicated to a 
mobile web version, if that hasn't already happened.

To my way of thinking, there really are no current products out there that 
do what MLO does.  However, MLO (Windows) almost does "too much" to the 
point of being complex and nearly unapproachable to a large chunk of the 
"basic GTD user" market, people who just want to plug in and go.  There are 
many competing (especially GTD-oriented) products that enable the "plug in 
and go" capability for novice users, but then break down when you try to do 
more complex things with them.  Right off the bat, many of them do not 
support an outlining approach for breaking down projects and tasks. I 
concluded I couldn't live with a tool that doesn't support outlining.

Though I personally don't use Macs, I think a Mac version could be a huge 
market opportunity for MLO, but would require a refactoring/rewrite of a 
large chunk of MLO code, along the lines I mentioned above, plus a way of 
testing across platforms.
I have observed that the Mac community includes a disproportionately high 
number of very enthusiastic people who would find a tool like MLO very 
useful.

If Andrey could find a way to pull off the rearchitecting along these 
lines, while simplifying the UI for novice users, and making it available 
on the major UI platforms, while preserving the powerful functionality 
enjoyed by MLO power users, there are almost no limits to the markets MLO 
could break into and be successful in.

In my mind, the most sensible way to get to a Mac version would be to first 
rearchitect to get to a Web+Cloud version, and then adapt the UI for the PC 
version (and future Mac version) to be a UI on top of running the core MLO 
services locally.  Possibly that's already what Andrey has in progress. 
 Trying to support a bunch of different platforms with a bunch of custom 
code on each platform, and in different languages, becomes sheer insanity 
for a small dev team to support and evolve.

But, absolutely, a Mac rich client version should be in discussion and on 
the drawing board at the same time as a Web/Cloud version, and I would see 
them as complementary efforts, to the extent they force the architectural 
issue of separating out non-UI core services.  A Web/cloud version is, 
however, (my opinion) by far the bigger market opportunity.

James

On Monday, November 25, 2013 9:07:06 AM UTC-8, Adam Wiseman wrote:
>
> Dammit, Mark, your rational and mostly valid arguments have foiled my 
> intentions to write a skeptical rebuttal.  But here's my proposal for a way 
> Andrey can reach a much broader, cross-platform audience:  Why not develop 
> a MLO webapp and move to a subscription-based model for access to said 
> webapp?  It would not be all that difficult to take his existing 
> client-side code and create a backend server application that would run the 
> rules engine, sync engine, and file system parts, while the webapp could 
> use much of the mobile app codebase (e.g. the Java code from the Android 
> App).  Granted, this would make client-side third party app integration 
> difficult, if not impossible (e.g. Outlook integration), but that would 
> actually enable him to continue to sell the "Premium" desktop version.  
> Look, I get what you and others are saying about the difficulties and 
> expense of porting to other platforms, especially given the extant 
> dominance of Windows PC's, but this is 2013, and to continue to succeed in 
> this highly interconnected and rapidly diversifying market, an enterprise 
> must seriously consider the near-necessity of maximizing reach and 
> accessibility, and one of the easiest ways to do this is with 
> cross-platform capable webapps.
> Just my $0.02 (USD).
> --Adam
>
> On Tuesday, December 4, 2012 4:23:39 PM UTC-5, Mark Levison 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<http://www.google.com/url?q=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FObject_Pascal&sa=D&sntz=1&usg=AFQjCNEuHI16ZAS1Mr92Cr4pI41qlrcC5w>)
>>  
>> - 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<http://www.google.com/url?q=http%3A%2F%2Fagilepainrelief.com%2Fnotesfromatooluser%2F2012%2F11%2Flearning-scrum-through-games-golidocks-iteration-ii.html&sa=D&sntz=1&usg=AFQjCNEt3Bg1EMZbvTMcjCWT2wgd199pTA>
>> )
>>
>> Cheers
>> Mark Levison
>> Agile Pain Relief 
>> Consulting<http://www.google.com/url?q=http%3A%2F%2Fagilepainrelief.com%2Fnotesfromatooluser&sa=D&sntz=1&usg=AFQjCNFxm-7xKbEWcHVvWlGD961Xlk3nqg>|
>>  
>> Writing<http://www.google.com/url?q=http%3A%2F%2Fagilepainrelief.com%2Fnotesfromatooluser%2F&sa=D&sntz=1&usg=AFQjCNHbu90vvTjFfn6KhD8TqQrw8FDJpg>
>> Proud Sponsor of Agile Tour Gatineau 
>> Ottawa<http://www.google.com/url?q=http%3A%2F%2Fgoagiletour.ca%2F&sa=D&sntz=1&usg=AFQjCNEcL3pxUrQGWAJ5yh_EOarUp5W7mw>Nov
>>  28, 
>> Toronto<http://www.google.com/url?q=http%3A%2F%2Fwww.torontoagilecommunity.org%2Fdisplay%2FPUBLIC%2FHome&sa=D&sntz=1&usg=AFQjCNFl9qMzWHJqZkSoVqwu82uj4qODOw>26
>>  and 
>> Montreal<http://www.google.com/url?q=http%3A%2F%2Fagilemontreal.ca%2Fagile-tour-2012%2F&sa=D&sntz=1&usg=AFQjCNFu9vhazkVQkf0CVqt_ldR8wgEyVA>24
>>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"MyLifeOrganized" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mylifeorganized.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mylifeorganized/80393bc5-77c1-4086-9eaf-bcb6f2de85a7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to