Atomic Design, organism in organism? - responsive-design

Atomic Design seem to be an interesting methodology to construct an UX structure. But can one organism contain others organisms ?

According to this React implementation of Atomic Design:
An organism is a group of atoms, molecules and/or other organisms:
https://github.com/diegohaz/arc/wiki/Atomic-Design

Yes it is completely okay to include an organism inside another organism.
An organism is actually: A group of atoms, molecules and/or other organisms.

Related

How to keep naming conventions clear in react.js?

I try to help my team and get my code very organised and DRY . In order to scale with flexibility.
I'm so new at this and I do have a question: do this libraries (flux, reflux,etc) use a certain naming conventions ?
Because I try to build file structure with atomic design patterns in react.js ... and an extra help would be great please.
Insights needed here from you guys.
Thanx
if you use atomic design for components:
The first letter stands for an item category: atom, molecule,
organism. The second word is an element type. The rest is used to
describe variations of an element.
Every atom-, molecule- and organism-layer or group within your design
mockups should be named accordingly.
and for styles I recommend use BEM :
BEM names intentionally use double underscores and double hyphens
instead of single to separate Block-Element-Modifier.

Is it possible to filter the class display in Protegé?

I am designing a new ontology, which references the (very large!) Ontology of Units of Measure (om-2): http://www.ontology-of-units-of-measure.org/page/om-2
This makes it hard to work with Protegé because it seems that I am left with one of two bad alternatives:
The small number of classes in my ontology are swamped in the display by om-2 classes (displaying with prefix helps, but only a little).
I don't include om-2 in the Protegé project and just refer to classes from there. As far as I can tell, this hampers Protegé's ability to work with a DL reasoner.
Is there some way to tell Protegé to filter the display and hide the om-2 classes? Being able to toggle this would be a huge help.

Writing action theories in OWL + SWRL: possible?

In order to solve symbolic planning problems we write action theories.
Popular languages for writing action theories are STRIPS and ADL.
For describing an action we need to provide:
preconditions
effects
For example, in a robot domain, we have Robot and Object classes, and the closeTo and holding properties.
The action pickUp(?robot, ?object) is possible if closeTo(?robot, ?object) holds, and also forall ?o in Object . not holding(?robot, ?o).
How would one represent preconditions with OWL and/or SWRL?
How about action effects?
The Knowrob project suggests that it is possible to use the Qualitative Process Theory (QPT) in combination with OWL-Markup language for implementing actions. A possible precondition would be [1] :
rdf_triple(knowrob:'thermicallyConnectedTo', Dough, HeatSource),
But it was never demonstrated, that this prolog-spaghetti-code will work. OWL is not a real programming language, it's more like a markup language like json. To formalize processes in a deklarative form is a academic quiz but has no relevance for gamecoding or real robotprogramming.

What impact does using these facilities have on orthogonality?

I am reading The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, David Thomas. When I was reading about a term called orthogonality I was thinking that I am getting it right. I was understanding it very well. However, at the end of the chapter a few questions were asked to measure the level of understanding of the subject. While I was trying to answer those questions to myself I realized that I haven't understood it perfectly. So to clarify my understandings I am asking those questions here.
C++ supports multiple inheritance, and Java allows a class to
implement multiple interfaces. What impact does using these facilities
have on orthogonality? Is there a difference in impact between using multiple
inheritance and multiple interfaces?
There are actually three questions bundled up here: (1) What is the impact of supporting multiple inheritance on orthogonality? (2) What is the impact of implementing multiple interfaces on orthogonality? (3) What is the difference between the two sorts of impact?
Firstly, let us get to grips with orthogonality. In The Art of Unix Programming, Eric Raymond explains that "In a purely orthogonal design, operations do not have side effects; each action (whether it's an API call, a macro invocation, or a language operation) changes just one thing without affecting others. There is one and only one way to change each property of whatever system you are controlling."
So, now look at question (1). C++ supports multiple inheritance, so a class in C++ could inherit from two classes that have the same operation but with two different effects. This has the potential to be non-orthogonal, but C++ requires you to state explicitly which parent class has the feature to be invoked. This will limit the operation to only one effect, so orthogonality is maintained. See Multiple inheritance.
And question (2). Java does not allow multiple inheritance. A class can only derive from one base class. Interfaces are used to encode similarities which the classes of various types share, but do not necessarily constitute a class relationship. Java classes can implement multiple interfaces but there is only one class doing the implementation, so there should only be one effect when a method is invoked. Even if a class implements two interfaces which both have a method with the same name and signature, it will implement both methods simultaneously, so there should only be one effect. See Java interface.
And finally question (3). The difference is that C++ and Java maintain orthogonality by different mechanisms: C++ by demanding the the parent is explicitly specified, so there will be no ambiguity in the effect; and Java by implementing similar methods simultaneously so there is only one effect.
Irrespective of any number of interfaces/ classes you extend there will be only one implementation inside that class. Lets say your class is X.
Now orthogonality says - one change should affect only one module.
If you change your implementation of one interface in class X - will it affect other modules/classes using your class X ? Answer is no - because the other modules/classes are coding by interface not implementation.
Hence orthogonality is maintained.

Should tagging have hierarchies?

I have always viewed tags as completely different than the normal folder hierarchy model. I am building a system that needs tagging to tag sets of data. We had the db design all worked out, (pretty straightforward model) but a debate arose around the value of still having concepts of hierarchies within a world of tags.
On SOF, as an example, the only equivalent I see some of this by using - in some tag names like tagging; jquery, jquery-ui, jquery-ui-dialog so there is no inherent modeled relationship (just a naming convention).
Is there any conventional wisdom of best practices around how and if hierarchies should exist in a world of tagging?
I developed a portal that involved hierarchical tags. I can assure you that is a mess to manage :)
My solution then moved to a hybrid approach in which tags can be stand-alone or hiearchically handled but they reside in two different namespaces.
This because some tags can be seen as children of parents of other tags while others cannot, so for example dialog tag is a concept that is also indipendent from jquery so a content with both tags jquery dialog has implicitly the relationship needed.
Hierarchical should be used to express a kind of inheritance between concepts, eg. collections -> trees, lists, maps in which trees tag can be effectively included inside a collections tag.
In your example dialog and jquery are orthogonal and uncomparable, so it makes no sense to make one child of another.
The names "jquery", "jquery-ui", "jquery-ui-dialog" aren't tags, but the equivalent of file structure paths, hierarchical by nature.
If your data is easy to authoritatively categorize then present it as a tree. If users only see a few of their own tags (like in Gmail), you could make it possible to sort and nest the tag list and save that structure per user, separately from tags themselves. If there are great many tags with power distribution of content (for example if 10% of tags describe 90% of content) then a tag cloud can help.
In short, it depends on the data.
hierarchies have in general a disadvantage compared to sets.
think of bookmarks and tag-bundles like delicious.com.
i prefer to search for a set using sport and newer-than-1-week and ( english-language or chinese-language ) and not ( soccer or boxing ).

Resources