UtilCache bugs and coverage

[Adam Heath-2]

So, for the past week, I've been working on automated test cases for
UtilCache.  I can say that I've got the hardest parts done, namely,
ttl and ref based testing.

While writing the test cases, I discovered several bugs.  One of the
biggies was very bad LRU handling.  This required some major
rewriting, so that ttl and ref clearing is no longer polled.  There
are background threads that magically remove items as soon as they are
available for clearing.  This can actually reduce memory, because now
as soon as tll or ref fires, the item gets removed from the cache,
instead of waiting until some time later when a get is called.

Additionally, CacheLineTable is no longer around, I've merged it into
UtilCache directly.  I consider any of the CacheLine classes to be
completely internal, and should not be used outside of UtilCache.
Since expiration and invalidation are no longer a polled system, those
methods actually no longer exist.  So any such methods that were
involved with CacheLine management I am planning on removing.

Below are the list of bugs that I have completely identified, and
fixed.  There may be more, and my explanation may not be entirely
accurate.  I should have this ready to be committed by the end of the
week.  Afterwords, I'll finally start writing docs on all the
git/testing stuff I've been talking about.

==
* BUG: LRU out of order
  * BUG: containsKey() calls get(), which records an access
  * BUG: clear() notes removal before calling clear, and calls
    get, which records an access in LRU mode.
* BUG: With a positive expireTime, setting to any other positive
  value has no effect.
* BUG: when an item was expired due to a ttl, or invalidated
  when a soft ref was cleared, the disk store would have the
  item removed as well.  So the disk store actually gave no
  benefit whatsoever.
* BUG: CacheLineTable stored CacheLine instances in the file
  store, and didn't handle changing them to the proper reference
  when reading from disk, if the reference type had been changed.
  If the ref type was changed, then the disk-based ref type would
  be changed, but just doing a fetch from disk wouldn't handle
  the ref type change.  It is possible that upon reading the
  serialized CacheLine from disk, that a soft ref would be
  immediately cleared.
* BUG: CacheLineTable synchronized on (this) when creating the
  static, shared jdbmMgr; never noticed in production, as ofbiz
  startup is single threaded.
* BUG: CacheLineTable created a global jdbmMgr, using the
  per-cache fileSystemStore location.
* BUG: Using a fileStore without SoftReference makes no sense.
  All objects might have a ttl attached, which caused memory and
  disk access for put/remove, or, without a cache, the memory
  store would always be the same as the disk store.
* BUG: CacheLineTable.remove called fileTable.remove, but didn't
  call jdbmMgr.commit().
* BUG: getCacheLineKeys(), and other collection based
  meta-methods, didn't handle invalidation or expiration.
* FEATURE: CacheLineTable didn't add fetched values from disk
  into memory, to take advantage of LRU and soft ref processing.

[Michael Xu (xudong)]

hi Adam,

Thanks for your work. Cache layer is critical for ofbiz as ERP system.

Just one quick question: There are a lot of cache frameworks (Personally I
like Apache JCS very much) out there. Why ofbiz has to have its own
implement?

In my opinion, we have two ways to reduce bugs. Write more test codes, or
write less product codes. Maybe we can replace ofbiz components with some
existing components (say cache) or separate ofbiz components as sub projects
or just totally new project to attract more projects to use (say, entity
engine).

--
Regards,
Michael Xu (xudong)



On Mon, Mar 22, 2010 at 11:47 PM, Adam Heath <[hidden email]> wrote:

> So, for the past week, I've been working on automated test cases for
> UtilCache.  I can say that I've got the hardest parts done, namely,
> ttl and ref based testing.
>
> While writing the test cases, I discovered several bugs.  One of the
> biggies was very bad LRU handling.  This required some major
> rewriting, so that ttl and ref clearing is no longer polled.  There
> are background threads that magically remove items as soon as they are
> available for clearing.  This can actually reduce memory, because now
> as soon as tll or ref fires, the item gets removed from the cache,
> instead of waiting until some time later when a get is called.
>
> Additionally, CacheLineTable is no longer around, I've merged it into
> UtilCache directly.  I consider any of the CacheLine classes to be
> completely internal, and should not be used outside of UtilCache.
> Since expiration and invalidation are no longer a polled system, those
> methods actually no longer exist.  So any such methods that were
> involved with CacheLine management I am planning on removing.
>
> Below are the list of bugs that I have completely identified, and
> fixed.  There may be more, and my explanation may not be entirely
> accurate.  I should have this ready to be committed by the end of the
> week.  Afterwords, I'll finally start writing docs on all the
> git/testing stuff I've been talking about.
>
> ==
> * BUG: LRU out of order
>  * BUG: containsKey() calls get(), which records an access
>  * BUG: clear() notes removal before calling clear, and calls
>    get, which records an access in LRU mode.
> * BUG: With a positive expireTime, setting to any other positive
>  value has no effect.
> * BUG: when an item was expired due to a ttl, or invalidated
>  when a soft ref was cleared, the disk store would have the
>  item removed as well.  So the disk store actually gave no
>  benefit whatsoever.
> * BUG: CacheLineTable stored CacheLine instances in the file
>  store, and didn't handle changing them to the proper reference
>  when reading from disk, if the reference type had been changed.
>  If the ref type was changed, then the disk-based ref type would
>  be changed, but just doing a fetch from disk wouldn't handle
>  the ref type change.  It is possible that upon reading the
>  serialized CacheLine from disk, that a soft ref would be
>  immediately cleared.
> * BUG: CacheLineTable synchronized on (this) when creating the
>  static, shared jdbmMgr; never noticed in production, as ofbiz
>  startup is single threaded.
> * BUG: CacheLineTable created a global jdbmMgr, using the
>  per-cache fileSystemStore location.
> * BUG: Using a fileStore without SoftReference makes no sense.
>  All objects might have a ttl attached, which caused memory and
>  disk access for put/remove, or, without a cache, the memory
>  store would always be the same as the disk store.
> * BUG: CacheLineTable.remove called fileTable.remove, but didn't
>  call jdbmMgr.commit().
> * BUG: getCacheLineKeys(), and other collection based
>  meta-methods, didn't handle invalidation or expiration.
> * FEATURE: CacheLineTable didn't add fetched values from disk
>  into memory, to take advantage of LRU and soft ref processing.
>

[Adam Heath-2]

Michael Xu (xudong) wrote:

> hi Adam,
>
> Thanks for your work. Cache layer is critical for ofbiz as ERP system.
>
> Just one quick question: There are a lot of cache frameworks (Personally I
> like Apache JCS very much) out there. Why ofbiz has to have its own
> implement?
>
> In my opinion, we have two ways to reduce bugs. Write more test codes, or
> write less product codes. Maybe we can replace ofbiz components with some
> existing components (say cache) or separate ofbiz components as sub projects
> or just totally new project to attract more projects to use (say, entity
> engine).

I've looked at ehcache, and have plans to convert to that eventually.
 First, however, is to get our code functionting correctly, with no
bugs, and with good test cases on the existing interface(UtilCache),
then the implementation underneath can be switch, while keeping the
same set of test cases.

[David E. Jones-2]

On Mar 22, 2010, at 11:07 AM, Adam Heath wrote:

> Michael Xu (xudong) wrote:
>> hi Adam,
>>
>> Thanks for your work. Cache layer is critical for ofbiz as ERP system.
>>
>> Just one quick question: There are a lot of cache frameworks (Personally I
>> like Apache JCS very much) out there. Why ofbiz has to have its own
>> implement?
>>
>> In my opinion, we have two ways to reduce bugs. Write more test codes, or
>> write less product codes. Maybe we can replace ofbiz components with some
>> existing components (say cache) or separate ofbiz components as sub projects
>> or just totally new project to attract more projects to use (say, entity
>> engine).
>
> I've looked at ehcache, and have plans to convert to that eventually.
> First, however, is to get our code functionting correctly, with no
> bugs, and with good test cases on the existing interface(UtilCache),
> then the implementation underneath can be switch, while keeping the
> same set of test cases.

I looked around a bit recently to see if there was a cache project that could replace the UtilCache stuff.

OSCache and Ehcache both look pretty good, and Jakarta JCS looks okay, and of the various I read about Ehcache looks like the most feature-rich (especially for distributed caches and such). Ehcache also tracks statistics much like the OFBiz UtilCache stuff does.

None of these appear to support soft-reference cache entries, but maybe that's not a big deal and it would be better to do size/entries limiting instead anyway (they all have good eviction algorithms).

Are there any other cache projects that other people like?

Should we deprecate the soft-reference support in order to more easily plugin a separate cache library?

-David

[Adam Heath-2]

David E Jones wrote:

> On Mar 22, 2010, at 11:07 AM, Adam Heath wrote:
>
>> Michael Xu (xudong) wrote:
>>> hi Adam,
>>>
>>> Thanks for your work. Cache layer is critical for ofbiz as ERP system.
>>>
>>> Just one quick question: There are a lot of cache frameworks (Personally I
>>> like Apache JCS very much) out there. Why ofbiz has to have its own
>>> implement?
>>>
>>> In my opinion, we have two ways to reduce bugs. Write more test codes, or
>>> write less product codes. Maybe we can replace ofbiz components with some
>>> existing components (say cache) or separate ofbiz components as sub projects
>>> or just totally new project to attract more projects to use (say, entity
>>> engine).
>> I've looked at ehcache, and have plans to convert to that eventually.
>> First, however, is to get our code functionting correctly, with no
>> bugs, and with good test cases on the existing interface(UtilCache),
>> then the implementation underneath can be switch, while keeping the
>> same set of test cases.
>
> I looked around a bit recently to see if there was a cache project that could replace the UtilCache stuff.
>
> OSCache and Ehcache both look pretty good, and Jakarta JCS looks okay, and of the various I read about Ehcache looks like the most feature-rich (especially for distributed caches and such). Ehcache also tracks statistics much like the OFBiz UtilCache stuff does.
>
> None of these appear to support soft-reference cache entries, but maybe that's not a big deal and it would be better to do size/entries limiting instead anyway (they all have good eviction algorithms).
>
> Are there any other cache projects that other people like?
>
> Should we deprecate the soft-reference support in order to more easily plugin a separate cache library?

ehcache has soft-ref support.  Do a google search for 'ehcache
softreference'

Replacing UtilCache is not a good plan.  It's best to keep that
api(with maybe a small change, if needed).  Then swap out what
UtilCache does under the scenes, based on what we decide.  But, as I
said, before we can do that, we need to test the current design, so
that when/if we do change, we can know that we haven't broken anything
that's already being tested.

[David E. Jones-2]

On Mar 22, 2010, at 1:52 PM, Adam Heath wrote:

> David E Jones wrote:
>> On Mar 22, 2010, at 11:07 AM, Adam Heath wrote:
>>
>>> Michael Xu (xudong) wrote:
>>>> hi Adam,
>>>>
>>>> Thanks for your work. Cache layer is critical for ofbiz as ERP system.
>>>>
>>>> Just one quick question: There are a lot of cache frameworks (Personally I
>>>> like Apache JCS very much) out there. Why ofbiz has to have its own
>>>> implement?
>>>>
>>>> In my opinion, we have two ways to reduce bugs. Write more test codes, or
>>>> write less product codes. Maybe we can replace ofbiz components with some
>>>> existing components (say cache) or separate ofbiz components as sub projects
>>>> or just totally new project to attract more projects to use (say, entity
>>>> engine).
>>> I've looked at ehcache, and have plans to convert to that eventually.
>>> First, however, is to get our code functionting correctly, with no
>>> bugs, and with good test cases on the existing interface(UtilCache),
>>> then the implementation underneath can be switch, while keeping the
>>> same set of test cases.
>>
>> I looked around a bit recently to see if there was a cache project that could replace the UtilCache stuff.
>>
>> OSCache and Ehcache both look pretty good, and Jakarta JCS looks okay, and of the various I read about Ehcache looks like the most feature-rich (especially for distributed caches and such). Ehcache also tracks statistics much like the OFBiz UtilCache stuff does.
>>
>> None of these appear to support soft-reference cache entries, but maybe that's not a big deal and it would be better to do size/entries limiting instead anyway (they all have good eviction algorithms).
>>
>> Are there any other cache projects that other people like?
>>
>> Should we deprecate the soft-reference support in order to more easily plugin a separate cache library?
>
> ehcache has soft-ref support.  Do a google search for 'ehcache
> softreference'

Sorry, I looked through a few things and I'm not seeing it.

> Replacing UtilCache is not a good plan.  It's best to keep that
> api(with maybe a small change, if needed).  Then swap out what
> UtilCache does under the scenes, based on what we decide.

Is there any possibility that this is what I meant? It is the only logical way after all...

-David


> But, as I
> said, before we can do that, we need to test the current design, so
> that when/if we do change, we can know that we haven't broken anything
> that's already being tested.

[Marc Morin]

We have also notice that the cache can get polluted with contents from a rolledback transaction!!  Also, the visibility of the objects doesn't respect the transaction boundaries....

This has caused some problems, we haven't fixed it yet.... so no patch to contribute... sorry.

----- "Adam Heath" <[hidden email]> wrote:

> David E Jones wrote:
> > On Mar 22, 2010, at 11:07 AM, Adam Heath wrote:
> >
> >> Michael Xu (xudong) wrote:
> >>> hi Adam,
> >>>
> >>> Thanks for your work. Cache layer is critical for ofbiz as ERP
> system.
> >>>
> >>> Just one quick question: There are a lot of cache frameworks
> (Personally I
> >>> like Apache JCS very much) out there. Why ofbiz has to have its
> own
> >>> implement?
> >>>
> >>> In my opinion, we have two ways to reduce bugs. Write more test
> codes, or
> >>> write less product codes. Maybe we can replace ofbiz components
> with some
> >>> existing components (say cache) or separate ofbiz components as
> sub projects
> >>> or just totally new project to attract more projects to use (say,
> entity
> >>> engine).
> >> I've looked at ehcache, and have plans to convert to that
> eventually.
> >> First, however, is to get our code functionting correctly, with no
> >> bugs, and with good test cases on the existing
> interface(UtilCache),
> >> then the implementation underneath can be switch, while keeping
> the
> >> same set of test cases.
> >
> > I looked around a bit recently to see if there was a cache project
> that could replace the UtilCache stuff.
> >
> > OSCache and Ehcache both look pretty good, and Jakarta JCS looks
> okay, and of the various I read about Ehcache looks like the most
> feature-rich (especially for distributed caches and such). Ehcache
> also tracks statistics much like the OFBiz UtilCache stuff does.
> >
> > None of these appear to support soft-reference cache entries, but
> maybe that's not a big deal and it would be better to do size/entries
> limiting instead anyway (they all have good eviction algorithms).
> >
> > Are there any other cache projects that other people like?
> >
> > Should we deprecate the soft-reference support in order to more
> easily plugin a separate cache library?
>
> ehcache has soft-ref support.  Do a google search for 'ehcache
> softreference'
>
> Replacing UtilCache is not a good plan.  It's best to keep that
> api(with maybe a small change, if needed).  Then swap out what
> UtilCache does under the scenes, based on what we decide.  But, as I
> said, before we can do that, we need to test the current design, so
> that when/if we do change, we can know that we haven't broken
> anything
> that's already being tested.

[Adam Heath-2]

Marc Morin wrote:
> We have also notice that the cache can get polluted with contents from a rolledback transaction!!  Also, the visibility of the objects doesn't respect the transaction boundaries....
>
> This has caused some problems, we haven't fixed it yet.... so no patch to contribute... sorry.

Code that modifies entities should not be calling caching variants of
the delegator.

[David E. Jones-2]

On Mar 22, 2010, at 3:03 PM, Adam Heath wrote:

> Marc Morin wrote:
>> We have also notice that the cache can get polluted with contents from a rolledback transaction!!  Also, the visibility of the objects doesn't respect the transaction boundaries....
>>
>> This has caused some problems, we haven't fixed it yet.... so no patch to contribute... sorry.
>
> Code that modifies entities should not be calling caching variants of
> the delegator.

It shouldn't even be able to... entities from the cache should be set to read-only (they used to be anyway).

There is still a potential for problems here though, especially if you are using a ReadUncommitted tx isolation level (ie something is read from the db and gets into the cache that hasn't been committed yet).

Whatever the case, this is correct: there is no transaction isolation in the cache.

-David

[gomola]

Hey everyone in dev land...

Bruno and I are working on improving the interface for Tomahawk, we
wanted to get opinions from everyone about the most used 9 apps on ofbiz
for top level jump point for ofbiz so we can build a user interface here
with help points, etc, a type of productivity dash board to make tasks
easier to get started on. The interface, while improved, has a glut of
information that a user is just expected to know proves difficult for
most new users, making their head pop off (I've seen it, it is gross)
trying to get a handle on everything.

There are some obvious ones, but please send a response in a numbered list.

[Adam Heath-2]

David E Jones wrote:

> On Mar 22, 2010, at 3:03 PM, Adam Heath wrote:
>
>> Marc Morin wrote:
>>> We have also notice that the cache can get polluted with contents from a rolledback transaction!!  Also, the visibility of the objects doesn't respect the transaction boundaries....
>>>
>>> This has caused some problems, we haven't fixed it yet.... so no patch to contribute... sorry.
>> Code that modifies entities should not be calling caching variants of
>> the delegator.
>
> It shouldn't even be able to... entities from the cache should be set to read-only (they used to be anyway).

It's not that said code is trying to modify entities that are already
in the cache.

It's that some entity is modified, then this supposed code calls a
caching variant, so the newly created value gets stored in the cache.

To make it more succinct, code that modifies database values can not
*ever* call a delegator caching variant.

Actually, how about if we modify the delegator to see if a transaction
is active for the current thread, and throw an exception if a cache
store is attempted?

[Marc Morin]

Or make the caching system easier to use.... copy on write, and transactional....  
----- "Adam Heath" <[hidden email]> wrote:

> David E Jones wrote:
> > On Mar 22, 2010, at 3:03 PM, Adam Heath wrote:
> >
> >> Marc Morin wrote:
> >>> We have also notice that the cache can get polluted with contents
> from a rolledback transaction!!  Also, the visibility of the objects
> doesn't respect the transaction boundaries....
> >>>
> >>> This has caused some problems, we haven't fixed it yet.... so no
> patch to contribute... sorry.
> >> Code that modifies entities should not be calling caching variants
> of
> >> the delegator.
> >
> > It shouldn't even be able to... entities from the cache should be
> set to read-only (they used to be anyway).
>
> It's not that said code is trying to modify entities that are already
> in the cache.
>
> It's that some entity is modified, then this supposed code calls a
> caching variant, so the newly created value gets stored in the cache.
>
> To make it more succinct, code that modifies database values can not
> *ever* call a delegator caching variant.
>
> Actually, how about if we modify the delegator to see if a
> transaction
> is active for the current thread, and throw an exception if a cache
> store is attempted?

[Jacques Le Roux]

I'd like to answer but sorry I'm not quite sure what to answer, it's about Icons?

Jacques

From: "Erik Schuessler" <[hidden email]>

> Hey everyone in dev land...
>
> Bruno and I are working on improving the interface for Tomahawk, we
> wanted to get opinions from everyone about the most used 9 apps on ofbiz
> for top level jump point for ofbiz so we can build a user interface here
> with help points, etc, a type of productivity dash board to make tasks
> easier to get started on. The interface, while improved, has a glut of
> information that a user is just expected to know proves difficult for
> most new users, making their head pop off (I've seen it, it is gross)
> trying to get a handle on everything.
>
> There are some obvious ones, but please send a response in a numbered list.
>

[gomola]

Ah yes, understood Jacques.

What I am working on is a set of icons for the main menu items on ofbiz.
I want to make the top 9 for a launch screen to make navigation easier
for new users.

Example icon menu items would be - Parties, Catalog, Content, etc.

Thanks
Erik

On 3/23/2010 2:59 PM, Jacques Le Roux wrote:

> I'd like to answer but sorry I'm not quite sure what to answer, it's
> about Icons?
>
> Jacques
>
> From: "Erik Schuessler" <[hidden email]>
>> Hey everyone in dev land...
>>
>> Bruno and I are working on improving the interface for Tomahawk, we
>> wanted to get opinions from everyone about the most used 9 apps on
>> ofbiz for top level jump point for ofbiz so we can build a user
>> interface here with help points, etc, a type of productivity dash
>> board to make tasks easier to get started on. The interface, while
>> improved, has a glut of information that a user is just expected to
>> know proves difficult for most new users, making their head pop off
>> (I've seen it, it is gross) trying to get a handle on everything.
>>
>> There are some obvious ones, but please send a response in a numbered
>> list.
>>
>

--
Erik Schuessler
Brainfood | Web ERP Solutions
4004 East Side Ave.
Dallas, TX 75226

[Tim Ruppert]

Off the top of my head the most 9 used apps would be (in no particular order and without redesigning the apps which is likely what we really need to do):

1. Order
2. Catalog
3. Party
4. Content
5. Accounting (assuming AR / AP inside here eventually)
6. Facility
7. Manufacturing
8. Marketing
9. Asset Maintenance

Cheers,
Ruppert

On Mar 23, 2010, at 5:50 PM, Erik Schuessler wrote:

> Ah yes, understood Jacques.
>
> What I am working on is a set of icons for the main menu items on ofbiz. I want to make the top 9 for a launch screen to make navigation easier for new users.
>
> Example icon menu items would be - Parties, Catalog, Content, etc.
>
> Thanks
> Erik
>
> On 3/23/2010 2:59 PM, Jacques Le Roux wrote:
>> I'd like to answer but sorry I'm not quite sure what to answer, it's about Icons?
>>
>> Jacques
>>
>> From: "Erik Schuessler" <[hidden email]>
>>> Hey everyone in dev land...
>>>
>>> Bruno and I are working on improving the interface for Tomahawk, we wanted to get opinions from everyone about the most used 9 apps on ofbiz for top level jump point for ofbiz so we can build a user interface here with help points, etc, a type of productivity dash board to make tasks easier to get started on. The interface, while improved, has a glut of information that a user is just expected to know proves difficult for most new users, making their head pop off (I've seen it, it is gross) trying to get a handle on everything.
>>>
>>> There are some obvious ones, but please send a response in a numbered list.
>>>
>>
>
> --
> Erik Schuessler
> Brainfood | Web ERP Solutions
> 4004 East Side Ave.
> Dallas, TX 75226
>

[gomola]

Thanks Tim. That is falling in line with what I am thinking, I want to
get a couple more opinions and I can work from there.

Thanks!
Erik

On 3/23/2010 6:58 PM, Tim Ruppert wrote:

> Off the top of my head the most 9 used apps would be (in no particular order and without redesigning the apps which is likely what we really need to do):
>
> 1. Order
> 2. Catalog
> 3. Party
> 4. Content
> 5. Accounting (assuming AR / AP inside here eventually)
> 6. Facility
> 7. Manufacturing
> 8. Marketing
> 9. Asset Maintenance
>
> Cheers,
> Ruppert
>
> On Mar 23, 2010, at 5:50 PM, Erik Schuessler wrote:
>
>    
>> Ah yes, understood Jacques.
>>
>> What I am working on is a set of icons for the main menu items on ofbiz. I want to make the top 9 for a launch screen to make navigation easier for new users.
>>
>> Example icon menu items would be - Parties, Catalog, Content, etc.
>>
>> Thanks
>> Erik
>>
>> On 3/23/2010 2:59 PM, Jacques Le Roux wrote:
>>      
>>> I'd like to answer but sorry I'm not quite sure what to answer, it's about Icons?
>>>
>>> Jacques
>>>
>>> From: "Erik Schuessler"<[hidden email]>
>>>        
>>>> Hey everyone in dev land...
>>>>
>>>> Bruno and I are working on improving the interface for Tomahawk, we wanted to get opinions from everyone about the most used 9 apps on ofbiz for top level jump point for ofbiz so we can build a user interface here with help points, etc, a type of productivity dash board to make tasks easier to get started on. The interface, while improved, has a glut of information that a user is just expected to know proves difficult for most new users, making their head pop off (I've seen it, it is gross) trying to get a handle on everything.
>>>>
>>>> There are some obvious ones, but please send a response in a numbered list.
>>>>
>>>>          
>>>        
>> --
>> Erik Schuessler
>> Brainfood | Web ERP Solutions
>> 4004 East Side Ave.
>> Dallas, TX 75226
>>
>>      
>
>    

--
Erik Schuessler
Brainfood | Web ERP Solutions
4004 East Side Ave.
Dallas, TX 75226

[Jacques Le Roux]

No real order (though a bit)

1. Catalog
2. Order
3. Party
4. Facility
5. Manufacturing
6. Accounting
7. Project
8. WorkEffort
9. SFA

What about Webtools?

Jacques

From: "Erik Schuessler" <[hidden email]>

> Thanks Tim. That is falling in line with what I am thinking, I want to get a couple more opinions and I can work from there.
>
> Thanks!
> Erik
>
> On 3/23/2010 6:58 PM, Tim Ruppert wrote:
>> Off the top of my head the most 9 used apps would be (in no particular order and without redesigning the apps which is likely
>> what we really need to do):
>>
>> 1. Order
>> 2. Catalog
>> 3. Party
>> 4. Content
>> 5. Accounting (assuming AR / AP inside here eventually)
>> 6. Facility
>> 7. Manufacturing
>> 8. Marketing
>> 9. Asset Maintenance
>>
>> Cheers,
>> Ruppert
>>
>> On Mar 23, 2010, at 5:50 PM, Erik Schuessler wrote:
>>
>>
>>> Ah yes, understood Jacques.
>>>
>>> What I am working on is a set of icons for the main menu items on ofbiz. I want to make the top 9 for a launch screen to make
>>> navigation easier for new users.
>>>
>>> Example icon menu items would be - Parties, Catalog, Content, etc.
>>>
>>> Thanks
>>> Erik
>>>
>>> On 3/23/2010 2:59 PM, Jacques Le Roux wrote:
>>>
>>>> I'd like to answer but sorry I'm not quite sure what to answer, it's about Icons?
>>>>
>>>> Jacques
>>>>
>>>> From: "Erik Schuessler"<[hidden email]>
>>>>
>>>>> Hey everyone in dev land...
>>>>>
>>>>> Bruno and I are working on improving the interface for Tomahawk, we wanted to get opinions from everyone about the most used 9
>>>>> apps on ofbiz for top level jump point for ofbiz so we can build a user interface here with help points, etc, a type of
>>>>> productivity dash board to make tasks easier to get started on. The interface, while improved, has a glut of information that
>>>>> a user is just expected to know proves difficult for most new users, making their head pop off (I've seen it, it is gross)
>>>>> trying to get a handle on everything.
>>>>>
>>>>> There are some obvious ones, but please send a response in a numbered list.
>>>>>
>>>>>
>>>>
>>> --
>>> Erik Schuessler
>>> Brainfood | Web ERP Solutions
>>> 4004 East Side Ave.
>>> Dallas, TX 75226
>>>
>>>
>>
>>
>
> --
> Erik Schuessler
> Brainfood | Web ERP Solutions
> 4004 East Side Ave.
> Dallas, TX 75226
>

[Scott Gray-2]

Hi Erik,

A few questions:
Where would this launch screen go?
What happens if everybody gives you a different list?
I'm sure this might be useful for new users, but will it get in the way of people who use OFBiz everyday in their job?

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

On 23/03/2010, at 5:50 PM, Erik Schuessler wrote:

> Ah yes, understood Jacques.
>
> What I am working on is a set of icons for the main menu items on ofbiz. I want to make the top 9 for a launch screen to make navigation easier for new users.
>
> Example icon menu items would be - Parties, Catalog, Content, etc.
>
> Thanks
> Erik
>
> On 3/23/2010 2:59 PM, Jacques Le Roux wrote:
>> I'd like to answer but sorry I'm not quite sure what to answer, it's about Icons?
>>
>> Jacques
>>
>> From: "Erik Schuessler" <[hidden email]>
>>> Hey everyone in dev land...
>>>
>>> Bruno and I are working on improving the interface for Tomahawk, we wanted to get opinions from everyone about the most used 9 apps on ofbiz for top level jump point for ofbiz so we can build a user interface here with help points, etc, a type of productivity dash board to make tasks easier to get started on. The interface, while improved, has a glut of information that a user is just expected to know proves difficult for most new users, making their head pop off (I've seen it, it is gross) trying to get a handle on everything.
>>>
>>> There are some obvious ones, but please send a response in a numbered list.
>>>
>>
>
> --
> Erik Schuessler
> Brainfood | Web ERP Solutions
> 4004 East Side Ave.
> Dallas, TX 75226
>

[Bruno Busco]

Hi Scott,
you know we are thinking ways to improve the OFBiz UI.
One of the things we are thinking is to have a page with large icon buttons.
Each icon should represent an application and would take the user to the
main application screen.
Erik is wondering what are the applications he should create icons for
first.

These icons could also be scaled down and shown near the application name in
the main navigation menu.

Other icons we will likely have are the ones for the main entities OFBiz
applications handles:
Party, Party group, Product, Product category, Product catalog, Agreement,
Invoice, Report etc.

For the page where the Applications icons will be shows we were thinking to
something like a portalPage with a sort of "quick-menu" portlet.
This would allow the user to customize its portalPage including/removing all
quick-menu iconized buttons he needs.

What do you think about?

-Bruno


2010/3/24 Scott Gray <[hidden email]>

> Hi Erik,
>
> A few questions:
> Where would this launch screen go?
> What happens if everybody gives you a different list?
> I'm sure this might be useful for new users, but will it get in the way of
> people who use OFBiz everyday in their job?
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 23/03/2010, at 5:50 PM, Erik Schuessler wrote:
>
> > Ah yes, understood Jacques.
> >
> > What I am working on is a set of icons for the main menu items on ofbiz.
> I want to make the top 9 for a launch screen to make navigation easier for
> new users.
> >
> > Example icon menu items would be - Parties, Catalog, Content, etc.
> >
> > Thanks
> > Erik
> >
> > On 3/23/2010 2:59 PM, Jacques Le Roux wrote:
> >> I'd like to answer but sorry I'm not quite sure what to answer, it's
> about Icons?
> >>
> >> Jacques
> >>
> >> From: "Erik Schuessler" <[hidden email]>
> >>> Hey everyone in dev land...
> >>>
> >>> Bruno and I are working on improving the interface for Tomahawk, we
> wanted to get opinions from everyone about the most used 9 apps on ofbiz for
> top level jump point for ofbiz so we can build a user interface here with
> help points, etc, a type of productivity dash board to make tasks easier to
> get started on. The interface, while improved, has a glut of information
> that a user is just expected to know proves difficult for most new users,
> making their head pop off (I've seen it, it is gross) trying to get a handle
> on everything.
> >>>
> >>> There are some obvious ones, but please send a response in a numbered
> list.
> >>>
> >>
> >
> > --
> > Erik Schuessler
> > Brainfood | Web ERP Solutions
> > 4004 East Side Ave.
> > Dallas, TX 75226
> >
>
>

[Adam Heath-2]

Scott Gray wrote:

> Hi Erik,
>
> A few questions:
> Where would this launch screen go?
> What happens if everybody gives you a different list?
> I'm sure this might be useful for new users, but will it get in the way of people who use OFBiz everyday in their job?
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 23/03/2010, at 5:50 PM, Erik Schuessler wrote:
>
>> Ah yes, understood Jacques.
>>
>> What I am working on is a set of icons for the main menu items on ofbiz. I want to make the top 9 for a launch screen to make navigation easier for new users.
>>
>> Example icon menu items would be - Parties, Catalog, Content, etc.

Exactly, everyone has their own list of 'important' sections of ofbiz.
 So, we(the community) need to provide a way for each end-user of
ofbiz to make their own 'landing' page.

As such, there needs to be icons for all the applications, and then
during deployment, you can choose which applications will show up on
the landing page.