4 key points

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

4 key points

Miroslav Mazel
Hi everyone,
I'm not really caught up on current OOo events, but I caught word (I tend to
scan through some mailing list messages, don't really have time to read them
all) that there's a OOo refresh in the making and was inspired to write an
e-mail detailing what I think is important to get done:
1. *The UI*
The UI is the single most important aspect of any piece of software. That's
how Apple makes its money: its products aren't feature packed and its
competitors usually already have the features its products have, but Apple's
hardware and software are really intuitive and comfortable to use.
The Renaissance project is shaping up really well. We need to get as many
people as possible to test it, to provide feedback, and to look into more
things we could do with the UI to make it more intuitive.
2. *The look*
Self-explanatory.
3. *The "feel"/the code*
OOo is infamous for being bloated. It's a famed memory and resource hog. So
here are a few streamlining suggestions:
a) Make secondary things into extensions. Take Google Chrome: it has put
basic things like the RSS feed indicator into extensions. I think we should
do a similar thing, but keep some of these basic extensions bundled in
OOo (but they would now be easily removable). A few things which could be
made into extensions: Wizards, templates, Gallery, Media player, Navigator,
Language tools, Collaboration tools, Help files, etc.
b) Use bits of the same code across the suite. (It's very peculiar that some
things, like shapes or tables, don't work exactly the same way across all
the applications, or that things like the zoom slider end up in one
application several releases before another.)
4. *The website*
The website holds the key to all of these, because that's where we get both
volunteers and customers. The website needs to be completely rethought, from
the ground up. The homepage needs a big, bright, warm download button and
needs to be more resolution-independent and colorful (judging by the
Feng-GUI heat map, where the OOo logo is the most distinctive part of the
page) in general. The whole site needs to be recategorized and made
browseable. All things related to projects (resources, mailing lists, links,
wiki pages, ...) need to be collected into one lucid, readable,
well-categorized project hub. Text needs to be drastically cut short,
projects and mailing lists that have been broken up into so many parts need
to be merged, and the new user routine has to be seriously simplified.
Seriously, there is just so much unnecessary complexity on the site right
now. And there needs to be an IdeaTorrent page, to provide a simple way to
collect ideas from people (because the current idea submission procedure is
too complicated and ineffective).

That's it. Of course, there are still problems like compatibility and
feature parity with Office to tackle, but I'd say those are secondary (we've
got the major compatibility problems solved, I think).
I'm only concerned about the speed we accomplish this with: things have been
moving pretty slowly around here, or so it seems.

I think we could do things a lot faster with a website refresh. That's the
thing we want to do first, because it'll get us more contributors. I'd
especially appreciate the IdeaTorrent page.

I'm also a bit concerned about online editing (with rising internet usage
and speeds, as well as the game-changing, web app-only Chrome OS), but I've
talked about that before...
--
This is a site which donates money to a custom charity when you search
(Google or Yahoo!): http://www.neoaid.com/
Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Miroslav Mazel
Hi again,
About the website: I think we should all work together to create something
good. So I encourage everyone to mockup some web pages (see
http://www.uxbooth.com/blog/15-desktop-online-wireframing-tools/ for some
nice wireframing tools), provide feedback for the mocked-up pages, and give
suggestions about how the website should look/work. I've done some basic
wireframes (very basic, very unclean, but I think it gives a good general
idea):
http://gomockingbird.com/mockingbird/index.html?project=d82ceee5a4806455c5a3a14094b62af90236f969,
plus I suggest we make a dark theme to conserve energy (Pixelmator has
a
really nice site in that respect). I'm also willing to do some basic web
writing (basic PHP, HTML, mySQL, that sort of stuff -- I really am just a
beginner).
So... I hope that people from art, ux, and the website start brainstorming
and working to create a more lucid version of the OOo website. And we can
also try working on re-branding OOo: Ubuntu 10.04 should be an inspiration (
http://www.omgubuntu.co.uk/2010/03/ubuntu-gets-new-themes-logo-more.html).

On Wed, Mar 24, 2010 at 6:01 AM, Irné Barnard <[hidden email]>wrote:

>
> What you're referring to is how I would describe a truly Object Oriented
> Application. I.e. an extremely small minimalist base application. It should
> actually be the same base for Writer, Calc, Base, etc. To side-step
> convusion with OOoBase, lets call it the startup module. This startup should
> do nothing more than read settings, dynamically load other modules (shared
> libraries), provide a consistent file / peripheral handling to the modules &
> provide the messaging system between separate modules. Writer (or a
> minimalist part thereof) would be one such module, Impress another. Draw and
> Impress could even have a common main module and thus share common code that
> way. All these modules should be similar in concept to plug-ins. And they
> should be able to build & extend on one another, as well as "replace" one
> another.
>
> But as you can see, that's not going to happen by snapping a finger. It
> would literally mean the entire OOo code needs to be rewritten.

Yes. And I'm thinking it should be, for a number of reasons:

   - To create a truly object-oriented application, as you described, which
   would:
      - Speed up OpenOffice.org
      - Facilitate programming
      - Make extentions more integrated
      - Make OOo work uniformly
   - To move OOo to the cloud (but it wouldn't have to host user files and
   would still be downloadable), which would:
      - Be revolutionary for businesses, which could now host, edit, and
      present their own files on their own websites. And Ubuntu One could allow
      users to edit their files in the browser. This space is as of yet
      unoccupied, so this is a huge opportunity for OOo.
      - Help OOo stay competitive (with companies like Microsoft, Google,
      Apple, and Adobe now making their own online office suites)
      - Make collaboration and other web features easier to incorporate
      - Guarantee that OOo is cross-platform (especially when Google's
      Chrome OS runs web apps only, and when OOo has no iPad/iPhone or Android
      version): all the modern platforms, be it mobile or desktop, can run web
      browsers
   - Because we're already planning deep changes, like the Renaissance UI,
   anyway

I really think a code rewrite inevitable if we want to keep OOo competitive.
Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Maximilian Odendahl-3

> I really think a code rewrite inevitable if we want to keep OOo competitive.

are you actually being serious? Certain parts definitely, but certainly
not everything.

As a rough estimate, see this from ohloh:

       
This calculator estimates how much it would cost to hire a team to write
this project from scratch:

Codebase 23,800,077
Effort (est.) 7676 Person Years
Avg. Salary $ 55.000 year

$ 422,159,217

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Mathias Bauer-3
Maximilian Odendahl wrote:

>> I really think a code rewrite inevitable if we want to keep OOo competitive.
>
> are you actually being serious? Certain parts definitely, but certainly
> not everything.
>
> As a rough estimate, see this from ohloh:
>
>
> This calculator estimates how much it would cost to hire a team to write
> this project from scratch:
>
> Codebase 23,800,077
> Effort (est.) 7676 Person Years
> Avg. Salary $ 55.000 year
>
> $ 422,159,217

"Rewrite it!" is something you usually will hear only from people that
are not familiar with large scale software development. IMHO still the
best comment on that was made by Joel Spolsky:

http://www.joelonsoftware.com/articles/fog0000000069.html

Regards,
Mathias

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Irné Barnard
On 2010-03-25 9:13:15, Mathias Bauer wrote:

> Maximilian Odendahl wrote:
>
>>> I really think a code rewrite inevitable if we want to keep OOo competitive.
>>
>> are you actually being serious? Certain parts definitely, but certainly
>> not everything.
>>
>> As a rough estimate, see this from ohloh:
>>
>>
>> This calculator estimates how much it would cost to hire a team to write
>> this project from scratch:
>>
>> Codebase 23,800,077
>> Effort (est.) 7676 Person Years
>> Avg. Salary $ 55.000 year
>>
>> $ 422,159,217
>
> "Rewrite it!" is something you usually will hear only from people that
> are not familiar with large scale software development. IMHO still the
> best comment on that was made by Joel Spolsky:
>
> http://www.joelonsoftware.com/articles/fog0000000069.html
>
> Regards,
> Mathias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

That's why I noted that it's not a trivial task. I think that estimate
is a bit over the top, but still it would be an astronomical figure.
Being a programmer myself (not employed as such though), I can easily
see just how much work it would be ... thus I'm not suggesting to just
do this.

I simply explained what would be necessary to get to what Miroslav
noted. Sorry if you read that I said it "should be rewritten", that was
actually the opposite of my intention.

--
Regards Irné Barnard

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Mathias Bauer-3
Irné Barnard wrote:

> On 2010-03-25 9:13:15, Mathias Bauer wrote:
>> Maximilian Odendahl wrote:
>>
>>>> I really think a code rewrite inevitable if we want to keep OOo competitive.
>>>
>>> are you actually being serious? Certain parts definitely, but certainly
>>> not everything.
>>>
>>> As a rough estimate, see this from ohloh:
>>>
>>>
>>> This calculator estimates how much it would cost to hire a team to write
>>> this project from scratch:
>>>
>>> Codebase 23,800,077
>>> Effort (est.) 7676 Person Years
>>> Avg. Salary $ 55.000 year
>>>
>>> $ 422,159,217
>>
>> "Rewrite it!" is something you usually will hear only from people that
>> are not familiar with large scale software development. IMHO still the
>> best comment on that was made by Joel Spolsky:
>>
>> http://www.joelonsoftware.com/articles/fog0000000069.html
>>
>> Regards,
>> Mathias
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> That's why I noted that it's not a trivial task. I think that estimate
> is a bit over the top, but still it would be an astronomical figure.
> Being a programmer myself (not employed as such though), I can easily
> see just how much work it would be ... thus I'm not suggesting to just
> do this.
>
> I simply explained what would be necessary to get to what Miroslav
> noted. Sorry if you read that I said it "should be rewritten", that was
> actually the opposite of my intention.
Actually I was referring to the statement made by Miroslav. I couldn't
read something from you as something else because I just didn't read
anything from you here. :-)

Regards,
Mathias


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Jaron Kuppers
Hello everyone,

Something I think we could add to Miroslav's list:
My biggest concern with OOo development is the barrier to entry for creating
specifications.  The process is a little ambiguous for new OOo volunteers
and the available documentation for writing a spec doesn't really help that
much.  The template looks different than a lot of the specifications I have
seen (which may be the result of a change in the template at some point?)
but I sometimes see new specifications using the old template and some using
the new... or maybe I am so confused that everything I said here is wrong.
;-)  I intended to improve the wiki pages on specifications to walk a new
OOo team member through as many details of the process as possible, but I,
unfortunately, don't feel comfortable doing that as I am not yet completely
comfortable with the process myself.

As for the whole code discussion:
I have only written what I call niche code, that is I wrote Finite Element
Simulation software for some of the largest super computers in the world.
 As a result, I won't claim to be a code writer (super efficient code for
parallel processing is a different beast than OOo), but I would argue that
"starting from scratch" at least for some components of OOo may be
beneficial, so that coding and behavior of tasks/objects is not only
consistent between modules but reduces the coding time needs when changes
are to be implemented.

If OOo's memory management is improvable through incremental code updates
why has that not been a priority?  Perhaps it is being improved and I just
don't know about it?

Out of curiosity, does anyone know how much it costs to run the OOo servers?
 More specifically, how much savings would be gleaned from lets say a 10%
reduction in the size of OOo?

Cheers,
Jaron
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] 4 key points

Miroslav Mazel
In reply to this post by Miroslav Mazel
On Thu, Mar 25, 2010 at 9:03 PM, Michael Adams <[hidden email]>wrote:

> On Wednesday 24 March 2010 11:14, Miroslav Mazel wrote:
> > 1. *The UI*
> > The UI is the single most important aspect of any piece of software.
> That's
> > how Apple makes its money: its products aren't feature packed and its
> > competitors usually already have the features its products have, but
> > Apple's hardware and software are really intuitive and comfortable to
> use.
> You have no conclusions from this observation - if you are an Apple Fanboy,
> fine, but what were you expecting us to absorb from their strategy.
>
The big lesson: the UI is what gets the customer. The iPhone and the iPod,
and even the first rendition of Mac OS, come to mind, since they all
revolutionized the industry with UI alone, but if you want other examples,
how about Firefox or Google Chrome? Even Windows has some UI niceties...

>
> > The Renaissance project is shaping up really well. We need to get as many
> > people as possible to test it, to provide feedback, and to look into more
> > things we could do with the UI to make it more intuitive.
> Ah - the look like Office 2007 team.
>
Actually, if you check out the newest iterations (use the Mixed Controls
mode), they're getting more and more unique and likeable (I don't like the
Ribbon copies either, but the mixed controls are an okay compromise, I
think).

>
> > 2. *The look*
> > Self-explanatory.
> Is part of the Graphical UI. Do you like it or not? I fail to see the
> purpose
> of raising this as an item in your list unless you tell us what you mean.
>
Yes, I was talking mostly about the GUI, although I feel that OOo could use
a general branding/art refresh, sure.

>
> > 3. *The "feel"/the code*
> > OOo is infamous for being bloated. It's a famed memory and resource hog.
> So
> > here are a few streamlining suggestions:
> > a) Make secondary things into extensions. Take Google Chrome: it has put
> > basic things like the RSS feed indicator into extensions. I think we
> should
> > do a similar thing, but keep some of these basic extensions bundled in
> > OOo (but they would now be easily removable). A few things which could be
> > made into extensions: Wizards, templates, Gallery, Media player,
> Navigator,
> > Language tools, Collaboration tools, Help files, etc.
> I don't really get your point here at all. You start slamming memory and
> resource usage, then providing a list of things, of which many only get
> loaded into memory when called upon anyway. What part of the help files is
> running before it has been requested by the user?
>

That was just a general call for streamlining, not only concerning memory,
but also disk usage and feature bloat. Help files were just presented as an
example of a fitting extension: something not necessary for the functioning
of the suite, something a lot of users can do without, something that should
be easily removed and easily put back.

>
> > b) Use bits of the same code across the suite. (It's very peculiar that
> > some things, like shapes or tables, don't work exactly the same way
> across
> > all the applications, or that things like the zoom slider end up in one
> > application several releases before another.)
> +1
>
> > 4. *The website*
> > The website holds the key to all of these, because that's where we get
> both
> > volunteers and customers. The website needs to be completely rethought,
> > from the ground up. The homepage needs a big, bright, warm download
> button
> > and needs to be more resolution-independent and colorful (judging by the
> > Feng-GUI heat map, where the OOo logo is the most distinctive part of the
> > page) in general.
>
> It just was. Where was your input into that process?
>
If I remember correctly, that refresh was 2 years ago. And I was among the
people who called for a more visible, direct Download button, among other
things. But that never amounted to anything...

>
> > The whole site needs to be recategorized and made
> > browseable. All things related to projects (resources, mailing lists,
> > links, wiki pages, ...) need to be collected into one lucid, readable,
> > well-categorized project hub. Text needs to be drastically cut short,
> > projects and mailing lists that have been broken up into so many parts
> need
> > to be merged, and the new user routine has to be seriously simplified.
> > Seriously, there is just so much unnecessary complexity on the site right
> > now. And there needs to be an IdeaTorrent page, to provide a simple way
> to
> > collect ideas from people (because the current idea submission procedure
> is
> > too complicated and ineffective).
> >
> > That's it. Of course, there are still problems like compatibility and
> > feature parity with Office to tackle, but I'd say those are secondary
> > (we've got the major compatibility problems solved, I think).
>


> Trying to achieve feature parity with a competitor only ever makes a
> product a
> copycat, not an innovative leader.

I'm not suggesting we copy things from competitors, not at all. I agree that
we should be innovative and independent. I'm just saying that if there's
something one can do with MS Office, there should be an extension that can
do the same thing, perhaps differently.

>  That is why the renaissance project GUI

should be offered as an addon only. I have it on good authority that people
> are resistant to change. The Office ribbon is one thing that has cause a
> lot
> of grief to customers with a good grasp on the traditional layout, This
> results in reduced output (how temporary this is, is debatable). No changes
> should be made without someone offering training. Where are the resources
> you
> propose for the training.

If you want OOo to be an innovative leader, you have to allow it to change.
Believe me, the Renaissance GUI has the customers' interests at heart. It's
a project that tries to create the best UI, not emulate the Ribbon
(although, sure, that may be what it seemed like at first). And for the
conservative/advanced users, there should be an extension for sure (plus the
OOo team stated, when they were first going into this, that they won't take
away the menu bar).
The Office Ribbon may have caused some grief for the advanced users, sure,
but it has improved the UX for the average user quite a bit.

>


> Changing a work site from Office 2003 to OO.o instead of Office 2007 was an
> opportunity that was mostly missed. Even then, training needs to be taken
> into the mix. I have heard of several half baked attempts to do just this
> that failed.
>
> > I'm only concerned about the speed we accomplish this with: things have
> > been moving pretty slowly around here, or so it seems.
> >
> > I think we could do things a lot faster with a website refresh. That's
> the
> > thing we want to do first, because it'll get us more contributors. I'd
> > especially appreciate the IdeaTorrent page.
> >
> > I'm also a bit concerned about online editing (with rising internet usage
> > and speeds, as well as the game-changing, web app-only Chrome OS), but
> I've
> > talked about that before...
>
> I hope you feel better after your rant. I do however see a lot of finger
> pointing without much practical help offered.
>
:) I feel great. I don't mean to criticize, I love OpenOffice.org and its
community is awesome.

I'm definitely willing to contribute (I can't contribute by coding, though)
-- just point me toward some meaningful task. All the projects seem kind of
stationary right now...

>
> --
> Michael
>



--
This is a site which donates money to a custom charity when you search
(Google or Yahoo!): http://www.neoaid.com/
Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Miroslav Mazel
In reply to this post by Irné Barnard
On Thu, Mar 25, 2010 at 9:25 AM, Irné Barnard <[hidden email]>wrote:

> On 2010-03-25 9:13:15, Mathias Bauer wrote:
>
>> Maximilian Odendahl wrote:
>>
>>  I really think a code rewrite inevitable if we want to keep OOo
>>>> competitive.
>>>>
>>>
>>> are you actually being serious? Certain parts definitely, but certainly
>>> not everything.
>>>
>>> As a rough estimate, see this from ohloh:
>>>
>>>
>>> This calculator estimates how much it would cost to hire a team to write
>>> this project from scratch:
>>>
>>> Codebase        23,800,077
>>> Effort (est.)   7676 Person Years
>>> Avg. Salary     $ 55.000 year
>>>
>>> $ 422,159,217
>>>
>>
>> "Rewrite it!" is something you usually will hear only from people that
>> are not familiar with large scale software development. IMHO still the
>> best comment on that was made by Joel Spolsky:
>>
>> http://www.joelonsoftware.com/articles/fog0000000069.html
>
>
Really good article, and I agree with it. However, I still believe OOo needs
a rewrite, but I don't want all the code to be thrown away. I mean something
more along the lines of making "fairly major architectural changes" by
rearranging and playing with the code.
And if that sort of code reuse is impossible, then OOo developers will
either have to rewrite a lot from scratch (I still think a lot of the code
could be reused) or live with the limitations of the current architecture
forever (like having replicate the same features in all of OOo's
applications), which will undoubtedly add up to a hefty amount of
programming time, too, as years go by.
I think right now, when we're planning a deep UI change and when web apps
are beginning to get more and more powerful and starting to replace desktop
apps, is a good time to decide on this.
P. S. Did OOo development really cost $422,159,217 so far?


>>
>> Regards,
>> Mathias
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
> That's why I noted that it's not a trivial task. I think that estimate is a
> bit over the top, but still it would be an astronomical figure. Being a
> programmer myself (not employed as such though), I can easily see just how
> much work it would be ... thus I'm not suggesting to just do this.
>
> I simply explained what would be necessary to get to what Miroslav noted.
> Sorry if you read that I said it "should be rewritten", that was actually
> the opposite of my intention.


> --
> Regards Irné Barnard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
This is a site which donates money to a custom charity when you search
(Google or Yahoo!): http://www.neoaid.com/
Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Mathias Bauer-3
Miroslav Mazel wrote:

>>> http://www.joelonsoftware.com/articles/fog0000000069.html
>>
>>
> Really good article, and I agree with it. However, I still believe OOo needs
> a rewrite, but I don't want all the code to be thrown away. I mean something
> more along the lines of making "fairly major architectural changes" by
> rearranging and playing with the code.

Well, that happens all the time. Several parts of OOo got an
architectural review and architectural overhaul. Just to name a few of
those parts where I was involved: the whole embedding code (OLE objects)
was rewritten to become a component based framework, the whole command
dispatching code has been rewritten, also as a component base framework,
and the same is true for all the code for loading documents.

In Writer some parts of the core have been improved to use better
defined interfaces, first steps for a model/view separation have bee
done, for Notes2 we used the new overlay graphics object etc. We also
are rearchitecturing our Word filters.

Currently we are re-architecturing parts of our code to make it
buildable with less and more sane dependencies. This e.g. lead to a
split of our largest code module into meanwhile 4 pieces.

I also know that the drawing layer is under heavy refactoring, and parts
of our UI code are also.

There is more and there is more to come, but - as Joel stated so nicely
- we can't go out of business for a few months or years, we have to
continue feature development. So code rework is stretched over many
years. The first refactorings I remember (rewriting the command
dispatching code) started 1996 or so, together with the "invention" of UNO.

> And if that sort of code reuse is impossible, then OOo developers will
> either have to rewrite a lot from scratch (I still think a lot of the code
> could be reused) or live with the limitations of the current architecture
> forever (like having replicate the same features in all of OOo's
> applications), which will undoubtedly add up to a hefty amount of
> programming time, too, as years go by.

I always find it interesting that so often "architecture" is used,
without defining what this exactly means. Moreover, UI most probably is
something that has the least dependencies on "architecture".

> I think right now, when we're planning a deep UI change and when web apps
> are beginning to get more and more powerful and starting to replace desktop
> apps, is a good time to decide on this.

In the worst case we could write a complete new UI and just leave the
old one in the code - but just don't use it. The OOo API offers a lot to
support this approach. That's what e.g. OOo4Kids has done.

> P. S. Did OOo development really cost $422,159,217 so far?

I doubt that anyone has calculated that exactly. From the number of
years we have worked on the code and from guestimations of the "run
rate" of our development group I think it could be a little bit less.
You know, we are better than the others, so we do more in less time. ;-)

Regards,
Mathias


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Johannes Eva
Hi Maximilian, Miroslav, Mathias and everybody!

http://www.joelonsoftware.com/articles/fog0000000069.html
Thank you Maximilian for linking this excellent article. I read it some
years ago, and had it in mind but couldn't find it anymore :-)

OOo is somewhat bloated, well yes! Many things need to be fixed and
improved: who says the contrary?
But it works really well for millions and millions of people. How comes
this bizarre "rewriting from scratch" idea so regularly?


Thank you very much Mathias for writing some details on what you and the
team are working on currently. Not only it is interesting, but I think
that it is very important that people know that this important work is
being done!
Some day, if you have some time left, maybe you could write a blog post
(GULLFOSS? Planet?) explaining all this to a broader audience?

I have been away 1 month, catching up reading the mailing list - and I'm
impressed with all the changes and vibrant life here :-)

All the best,
Johannes





Mathias Bauer wrote:

> Miroslav Mazel wrote:
>
>>>> http://www.joelonsoftware.com/articles/fog0000000069.html
>>>
>> Really good article, and I agree with it. However, I still believe OOo needs
>> a rewrite, but I don't want all the code to be thrown away. I mean something
>> more along the lines of making "fairly major architectural changes" by
>> rearranging and playing with the code.
>
> Well, that happens all the time. Several parts of OOo got an
> architectural review and architectural overhaul. Just to name a few of
> those parts where I was involved: the whole embedding code (OLE objects)
> was rewritten to become a component based framework, the whole command
> dispatching code has been rewritten, also as a component base framework,
> and the same is true for all the code for loading documents.
>
> In Writer some parts of the core have been improved to use better
> defined interfaces, first steps for a model/view separation have bee
> done, for Notes2 we used the new overlay graphics object etc. We also
> are rearchitecturing our Word filters.
>
> Currently we are re-architecturing parts of our code to make it
> buildable with less and more sane dependencies. This e.g. lead to a
> split of our largest code module into meanwhile 4 pieces.
>
> I also know that the drawing layer is under heavy refactoring, and parts
> of our UI code are also.
>
> There is more and there is more to come, but - as Joel stated so nicely
> - we can't go out of business for a few months or years, we have to
> continue feature development. So code rework is stretched over many
> years. The first refactorings I remember (rewriting the command
> dispatching code) started 1996 or so, together with the "invention" of UNO.
>
>> And if that sort of code reuse is impossible, then OOo developers will
>> either have to rewrite a lot from scratch (I still think a lot of the code
>> could be reused) or live with the limitations of the current architecture
>> forever (like having replicate the same features in all of OOo's
>> applications), which will undoubtedly add up to a hefty amount of
>> programming time, too, as years go by.
>
> I always find it interesting that so often "architecture" is used,
> without defining what this exactly means. Moreover, UI most probably is
> something that has the least dependencies on "architecture".
>
>> I think right now, when we're planning a deep UI change and when web apps
>> are beginning to get more and more powerful and starting to replace desktop
>> apps, is a good time to decide on this.
>
> In the worst case we could write a complete new UI and just leave the
> old one in the code - but just don't use it. The OOo API offers a lot to
> support this approach. That's what e.g. OOo4Kids has done.
>
>> P. S. Did OOo development really cost $422,159,217 so far?
>
> I doubt that anyone has calculated that exactly. From the number of
> years we have worked on the code and from guestimations of the "run
> rate" of our development group I think it could be a little bit less.
> You know, we are better than the others, so we do more in less time. ;-)
>
> Regards,
> Mathias
>

____________________________

Johannes Eva
http://www.johannes-eva.net/
____________________________


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] 4 key points

Elizabeth Matthis
Hi Johoannes,

On 04/02/10 19:20, Johannes Eva wrote:
> Hi Maximilian, Miroslav, Mathias and everybody!
>
> http://www.joelonsoftware.com/articles/fog0000000069.html
> Thank you Maximilian for linking this excellent article. I read it
> some years ago, and had it in mind but couldn't find it anymore :-)
>
Yes, I loved it, too. My thanks as well!
[...]
> I have been away 1 month, catching up reading the mailing list - and
> I'm impressed with all the changes and vibrant life here :-)
>
> All the best,
> Johannes
[...]
It is so good to have you back! Now with your help the UX community can
be more vibrant.
Did you catch my last GullFOSS blog?
;-)
Liz

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]