Just a Microsoft Office clone
by
bkazez
·
· Score: 3, Insightful
It's a pity that OpenOffice is just a visually unattractive clone of Microsoft Office, user interface flaws and all. The first time I downloaded it I hoped to find not just a free productivity suite but one that was better than Microsoft Office for the user -- simple, straightforward, and to the point. Instead, OpenOffice copies virtually every feature from Microsoft Office with very little innovation of its own.
Anyone want to have a go at rethinking word processing, spreadsheet, and presentation software?
Re:Just a Microsoft Office clone
by
soullessbastard
·
· Score: 4, Insightful
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
Yes, there are some folks rethinking the standard interfaces...such as Apple (with Keynote and Pages) and even Microsoft with Office 12 and earlier some of the UI design of Office:mac. On some platforms, it would even be possible to play around with alternative OOo interfaces by using OfficeBean (although I don't know of any off of the top of my head).
For office suites, however, I think the general interface paradigms are so commonplace now that any radical departure will be greeting by a nice resounding "WTF is this" from users. Case in point: OpenDoc. It was, in my opinion, a valiant attempt at shifting the focus for productivity suites off of individual applications and onto a free-form content-centric view. The idea never caught on with users, and ones I always saw trying to use it were just confused by the idea and were still asking questions like "what do I open to create a spreadsheet?".
Not to mention I can't get that stupid "I just did the Excel..." lady from the Video Professor commercial out of my head. With millions of users like that, I doubt things will really be able to change that much:)
ed
Re:Just a Microsoft Office clone
by
linguae
·
· Score: 4, Insightful
Anyone want to have a go at rethinking word processing, spreadsheet, and presentation software?
I would love to have a new, innovative, word processing software, spreadsheet software, and presentation software (although I use LaTeX and text editors for the former, so I'm not much of a word processor user anymore). However, OpenOffice's goal was never to become an innovative office suite (in the sense of revolutionizing word processors like Apple's Pages (or even LyX for that matter), revolutionizing spreadsheets like Lotus Improv, and presentations like Apple Keynote); it's goal was to provide 90% of MS Office's features and interface at a much lower price: free (as in beer and as in speech). And it does a decent job of doing that if you just can't afford MS Office (and, in some instances, a Windows or Mac OS license). I use OpenOffice on my computer. Even though I don't use it too often (I have been indoctrinated^Wintroduced to LaTeX, and don't have a need for spreadsheets and presentations [LaTeX can handle presentations, too]), I keep OpenOffice on my machine just in case I must work with MS Office documents.
OpenOffice is a very nice, pragmatic software project used for a free alternative to MS Office. OpenOffice isn't perfect and I actually prefer MS Office to OpenOffice for a few reasons (faster loading is the main key), but it is the no-cost solution to dealing with the MS world out there. OpenOffice didn't set out to become a revolutionary, innovative project. OpenOffice is an example of a program that tries to do a job that a $300+ program does, except offered for free.
Re:Just a Microsoft Office clone
by
the_womble
·
· Score: 2, Insightful
Exactly, if people were willing to sue something different if it was better, they would be using Lyx (far more productive than a word processor), Gnumeric (fast start-up, built in Monte-Carlo analysis, no bugs in the stats functions) etc. They could even stop using spreadsheets as databases (a pet hate of mine) given the existence of desktop databases.
The choice is there, users choose not to take it.
Re:Just a Microsoft Office clone
by
TuringTest
·
· Score: 2, Insightful
They could even stop using spreadsheets as databases (a pet hate of mine) given the existence of desktop databases.
They do that because users understand spreadsheets and they don't understand databases. No, really.
A spreadsheet is a good prototyping tool, it doesn't force structure on your data - you can play with it and throw it lots of data dumps, reformat them, reposition them, and the overall structure of the data emerges from all that dirty work. Contrast this with a database in which the first thing you have to do is define the schema - before even you can type in the first data instance.
So users choose not to change because they're using what works best for them. Spreadsheets are a really good metaphor for user development of datasets - its just that for the final version you should use a proper storage technology (a database), but to do that you really need an expert programmer.
-- Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Back to OOo 1.1.5
by
vanka
·
· Score: 5, Insightful
Does it have the new OOo 2.0 GUI? No? I'm not interested then, I'll wait for 2.0 to come out. From what I have seen, OOo 2.0 finally catches up to MS Office in terms of ease of use.
By the way, what's up with Slashdot? While the new look is kinda cool, why does it take several page reloads to display correctly in Firefox. I mean, you would think that they would made sure that the new design worked with Firefox.
I was expecting 2.0...
by
at_slashdot
·
· Score: 1, Insightful
Why does it take so much to release it? I've been using 1.99999999999 for half a year. I hope at least will be high quality.
-- "It is our choices, Harry, that show what we truly are, far more than our abilities."
-- Prof. Dumbledore
Unless you want to have a document which uses more than about 3GB of memory, what's the point of building it 64bit?
Firstly a 64bit program will be bigger and probably slower (dispite what the zealots tell you) because of having to drag double sized data across the memory bottleneck.
Seeing as the Opteron/Athlon64/Turion64 run 32bit applications fast natively there's no actual point (other than religious) to build and run an office product (or, indeed, most other applications) in 64bit mode.
As a general comment, "64bit program will be bigger and probably slower" is generally true. Things that benefit from 64-bit (databases, encryption) will speed up but everything else will slow down. Of course, when you speak x86-64 that isn't true at all. You get several advanatages in the design (more reigsters, flat memory, assume high level processor (no compat building for a Pentium 1)) which do speed it up.
In EDA tools, I've seen SPARC 64-bit binaries go slower and the x86-64 ones go quicker. That isn't a critcism of SPARC, it is just proof of the benefits of the x86-64 mode.
Anyway in THIS case I don't see any benefits of having a 64-bit OOo as such - the problem is if OOo is 32-bit, then it needs a 32-bit userland. So on my x86-64 boxes I've got a load of duplicated libraries (GTK etc) in 32-bit mode just to support OOo. If OOo was 64-bit, I simply would need less stuff. That has to be good right?
Myself, I've not seen a great number of x86_64 binaries go quicker at all. This is both under Linux with GCC and Portland C compilers with all the optimisations I can throw at it switched on and under Solaris x86 with GCC and Studio 10 compilers.
For purely integer code on our v40z's, v20z's and W2100z machines there seems to be a 50% drop in speed, for floating point scientific code generally a bit less. This is the same for FORTRAN as well. These are all Opteron with dual channel memory.
I've tried similar on an Athlon64 machine with single channel memory and the performance drop is far greater.
All the advantages of the extra registers seems to be offset by the extra memory overhead at the moment, at least on the codes we run.
--
Agrajag: "Oh no, not again!"
But how else can you do portable?
by
steve_l
·
· Score: 3, Insightful
As a member of the Ant team, I also have to bemoan their use of a non-standard build tool, given that there is pretty good support for C++ compiles in ant-contrib's , and with extra work C++ support could be improved.
without something portable like Ant or SCons, you end up needing either to
-build your own tools (this is what Microsoft's shared source version of.NET does; it builds things like NMAKE, their worst-in-class make tool, then builds the rest of the system)
-require a common toolchain on every box (e.g. Unix make+the unix commands; cygwin on windows)
The trouble with IDEs, is that they are either platform specific, or use their own configuration files to control the build. In Java Ant has finally become common enough (after 5 years) that it is broadly supported in IDEs, so you get the best of both worlds.
In C++ land, most people resort to the common toolchain, because only the ambitious fools with time on their hands bother to write their own build system. Does that mean it should't be done? No, just that it would be silly if every fairly large project came up with their own build tools. Instead every few years, we really ought to revisit the build processes and tools of the OSS projects, and see how they can be improved.
What I don't understand is why OO has such small limitations built into it. I understand that Excel is a very old app, with roots back in the 16 bit days. OO.o on the other hand is quite new. Why would they only allow first 32,000 and now 64,000 rows. You'd think they could make it handle at least 1,000,000 rows. Why do they build in such small limits?
--
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Slashdot Mirror
It's a pity that OpenOffice is just a visually unattractive clone of Microsoft Office, user interface flaws and all. The first time I downloaded it I hoped to find not just a free productivity suite but one that was better than Microsoft Office for the user -- simple, straightforward, and to the point. Instead, OpenOffice copies virtually every feature from Microsoft Office with very little innovation of its own.
Anyone want to have a go at rethinking word processing, spreadsheet, and presentation software?
Does it have the new OOo 2.0 GUI? No? I'm not interested then, I'll wait for 2.0 to come out. From what I have seen, OOo 2.0 finally catches up to MS Office in terms of ease of use.
By the way, what's up with Slashdot? While the new look is kinda cool, why does it take several page reloads to display correctly in Firefox. I mean, you would think that they would made sure that the new design worked with Firefox.
Why does it take so much to release it? I've been using 1.99999999999 for half a year. I hope at least will be high quality.
"It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
Unless you want to have a document which uses more than about 3GB of memory, what's the point of building it 64bit?
Firstly a 64bit program will be bigger and probably slower (dispite what the zealots tell you) because of having to drag double sized data across the memory bottleneck.
Seeing as the Opteron/Athlon64/Turion64 run 32bit applications fast natively there's no actual point (other than religious) to build and run an office product (or, indeed, most other applications) in 64bit mode.
Agrajag: "Oh no, not again!"
As a general comment, "64bit program will be bigger and probably slower" is generally true. Things that benefit from 64-bit (databases, encryption) will speed up but everything else will slow down. Of course, when you speak x86-64 that isn't true at all. You get several advanatages in the design (more reigsters, flat memory, assume high level processor (no compat building for a Pentium 1)) which do speed it up.
In EDA tools, I've seen SPARC 64-bit binaries go slower and the x86-64 ones go quicker. That isn't a critcism of SPARC, it is just proof of the benefits of the x86-64 mode.
Anyway in THIS case I don't see any benefits of having a 64-bit OOo as such - the problem is if OOo is 32-bit, then it needs a 32-bit userland. So on my x86-64 boxes I've got a load of duplicated libraries (GTK etc) in 32-bit mode just to support OOo. If OOo was 64-bit, I simply would need less stuff. That has to be good right?
Myself, I've not seen a great number of x86_64 binaries go quicker at all. This is both under Linux with GCC and Portland C compilers with all the optimisations I can throw at it switched on and under Solaris x86 with GCC and Studio 10 compilers.
For purely integer code on our v40z's, v20z's and W2100z machines there seems to be a 50% drop in speed, for floating point scientific code generally a bit less. This is the same for FORTRAN as well. These are all Opteron with dual channel memory.
I've tried similar on an Athlon64 machine with single channel memory and the performance drop is far greater.
All the advantages of the extra registers seems to be offset by the extra memory overhead at the moment, at least on the codes we run.
Agrajag: "Oh no, not again!"
As a member of the Ant team, I also have to bemoan their use of a non-standard build tool, given that there is pretty good support for C++ compiles in ant-contrib's , and with extra work C++ support could be improved.
.NET does; it builds things like NMAKE, their worst-in-class make tool, then builds the rest of the system)
without something portable like Ant or SCons, you end up needing either to
-build your own tools (this is what Microsoft's shared source version of
-require a common toolchain on every box (e.g. Unix make+the unix commands; cygwin on windows)
The trouble with IDEs, is that they are either platform specific, or use their own configuration files to control the build. In Java Ant has finally become common enough (after 5 years) that it is broadly supported in IDEs, so you get the best of both worlds.
In C++ land, most people resort to the common toolchain, because only the ambitious fools with time on their hands bother to write their own build system. Does that mean it should't be done? No, just that it would be silly if every fairly large project came up with their own build tools. Instead every few years, we really ought to revisit the build processes and tools of the OSS projects, and see how they can be improved.
I have to agree with Shani -- the web site is a deal killer. I couldn't get anyone I know to consider LyX over Word if I sent them to the web site.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
What I don't understand is why OO has such small limitations built into it. I understand that Excel is a very old app, with roots back in the 16 bit days. OO.o on the other hand is quite new. Why would they only allow first 32,000 and now 64,000 rows. You'd think they could make it handle at least 1,000,000 rows. Why do they build in such small limits?
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.