Anahita Project

Anahita Project's Articles

Rastin Mehr

Rastin Mehr

February 14 2017

What do we want to see in Anahita 4.4

Blossoms in WestEnd

The focus of #Anahita 4.3 was to completely remove Joomla from Anahita. The focus of next release will be #MobileFirst and developing a client server architecture where all the UI layouts and elements are generated in the browser using Javascript while the server side php becomes mostly an API.

This article describes the ideal scenarios that we are aiming to achieve.

Designing for Mobile First

The current release of Anahita is using Bootstrap 2.2.4 which is primarily developed for desktop devices while providing a responsive mode for mobile screens. Mobile traffic is now surpassing the desktop traffic on the web so it makes sense to treat mobile users as primary users. Latest releases of #Bootstrap and #MaterialDesign have already rewritten their libraries for the mobile devices as primary users. 

Quite likely we will be using the Material Design library for the next release of Anahita which seems to be more suitable for web applications compare to the Bootstrap library. We will be using #Sass instead of #LESS to write the CSS code. The built-in LESS compiler in Anahita will be removed and instead we will be using GruntJS to compile the Sass code into css files. All icons will be in scalable vector graphics SVG to ensure high quality rendering on all types screens. We'll also be using HTML5 semantic tags for all the layouts and UI elements. 

Designing for Mobile First is a further push towards minimalism by focusing on absolute essentials for every screen rendered by Anahita.

Related links:

  1. Sass:
  2. Material Design:
  3. Bootstrap:
  4. GruntJS:
  5. HTML5 Semantic Elements:

Rendering UIs on the Client side

Until now most of Anahita layouts and UI elements have been generated by the server side and sent to the browser where interactivity and styling is added using Javascript behaviours and CSS. 

In Anahita 4.4 we want all the layouts and UI elements to be generated in the browser. The server side will only send and receive data via a RESTful API. Technologies such as #ReactJS #VueJS or #RiotJS have already reached a mature state. ReactJS from Facebook is currently our first choice. Using ReactJS the HTML code is generated using JSX syntax. This way reusable web components are developed using Javascript for putting together more complex layouts and UI elements. 

Technologies such as #Flux by Facebook enable us to create a unidirectional data flow which means when data state changes, the UI automatically re-renders itself.

It is quite likely that #JQuery will be completely removed from Anahita. JQuery is good for animating DOM elements and making ajax calls, but not the best choice for generating HTML code or 2 way data binding. 

So expect more javascript and less php code in Anahita since all the php files responsible for rendering layouts and UI elements will be removed. 

Related links:

  1. ReactJS:
  2. VueJS:
  3. RiotJS:
  4. FluxJS:
  5. JQuery:

Improving RESTful API

Currently most of Anahita interfaces are loaded progressively by ajax calls that load snips of html code and insert them in the page that was initially loaded. This approach worked well for us and we have really pushed the limits of JQuery to do this for us. Now that we are going to construct all the layouts and UI elements in the browser using Javascript, all we need from the php back-end will be #JSON data. This will simplify our components since they no longer have to take care of rendering views and performing server redirects. All the controllers need to do is to offer the #RESTful #BREAD API endpoints for Browse, Read, Edit, Add, Delete. 

We currently have other API endpoints such as follow, unfollow, addcomment, deletecommnet, etc. Ideally we would want all controllers to only provide the BREAD operations. We want to follow the Convention Over Configuration concept, because it will make it easier for developers to identify and use the API endpoints. 

Related links:

SEO friendly pages for guest visitors

Rendering pages using javascript has one drawback. Google and other search engines cannot index the content of those pages. So a convention over configuration approach is required. What we need is for all detailed views (Read views) to be available as search engine friendly pages to the guest users. This is easy for the media nodes such as photos and articles. Actor pages are however more work. For an Actor profile, we will be rendering an SEO friendly alternative layout that represent the important information about the actor for the guest users. For example title, description, avatar, cover image, social graph, location graph, and top 10 recent stories and media.Guest users are the ones who haven't logged in to Anahita.

Some Anahita tribe members have recommended auto-generated sitemap files for Anahita. We need to do more research on that considering that there are limits on the number of items per sitemap or number of sitemaps per domain that we can used.We are also going to utilize #OpenGraph meta tags to improve how shared content from Anahita is presented on mainstream social networks.

Improving node presentation 

Since the advent of web2.0 and read-write-web applications, the user generated content has been displayed as database records and cards. We think it is important for a knowledge sharing platform to render its published content in an easy to consume and visually pleasing fashion. We want to improve how an individual node is displayed with as little as possible clutter around it. Services such as Medium, Vimeo, and 500px are quite inspiring with the way they present a piece of content with full width images, videos as well as large and readable typography.

Related links:

  1. Medium
  2. Vimeo
  3. 500px

Sharing Content

While improving the existing features in Anahita we also want to add a new feature which enables us to share content from an actor profile to another. We'll write more about this particular features once we have a proof of concept coded. 

Questions? Comments?

Post a comment and let me know 
4 people liked this
Scott Crawford
Scott Crawford
February 16 2017 Permalink
This certainly sounds exciting for the future of the platform - and the depth of description is very much appreciated!

For me personally it does raise a few questions:

1. Is it anticipated that the implementation will be incremental in nature? Or rather an eventual all-encompassing release that we should await before implementing across our own communities?

2. Will the end-result structure better facilitate "themeability"? I.e., currently while most of the views can be easily over-ridden and custom CSS applied, it has been necessary to "hack the core" in order to over-ride a good bit of front-end functionality such as the core anahita JS libraries, etc. It would be nice if the entirety of the front-end experience could be easily replaced if desired.
Rastin Mehr liked this
Rastin Mehr
Rastin Mehr
February 16 2017 Permalink
1. incremental is more likely. We still don't know all the design patterns for the client side Javascript and it will take some time to develop those. The new CSS framework however be done in a single release, because we cannot mix the current bootstrap with any of the new css frameworks.

2. of course, we want to stay customizable, but it will be done differently. In the new release we will be overriding javascript components and views instead of php ones. We'd need smarter gruntJS code to identify the overrides and include them in the compressed files. Static pages that need to be SEO friendly will still follow the conventional approach.
Roni Mmi
Roni Mmi
February 16 2017 Permalink
First Of All,

Your Script Is Designed For Who? Who Going To Use It.

1. People Who Want Make Personal, Community Or Business Social Network
2. Blogger, Articles Writer, Photographer
3. Brand, Small Business Owner.

What is the Basic Concept Of Current Web 2.0+

a website can publish photo, video, articles, user management, private messaging, sponsored advertisement, SEO, Faster loading website.

Who is your competitors ?

1. Wordpress
2. Ghost
3. Codecanyon Scripts -

what is the mainstream network / www ?
1. facebook
2. twitter
3. mobile web apps

what we can do to make anahita script to be very successful compare to 2016-2017

lets make it simple but unique + multi-purpose

1. hassle free - 1-Click Installation / Setup Method of Anahita Script
2. Admin Dashboard
3. Mobile Friendly
4. Super Fast Loading Time
5. A Complete redesign of Homefeed/Newsfeed / Profile / Group + Other Apps
6. Built-In SEO - Sitemap
7. admin have Ability To re-desisn any URL/Page From admin panel via drag-n-drop - Block system.
8. Auto QR Code For Any Public URL

Lets See What Apps We Needed

1. Photo Apps
2. Video Apps
3. Articles Apps ( Admin have ability to rename *blog apps* from admin control panel )
5. Private Messaging App
6. Sponsored Ads App
7. Brand Page Apps
8. Group Apps
9. Store App ( marketplace ) With Multiple Payment Gateway

for now.. thats enough to start or run any kind of successful website. this my opinions.

+ One more things - get anahita from - 1 click download in a zip file.
James Imani
James Imani
February 16 2017 Permalink
The approach is to get access to PHP-API per Javascript? Because that would be great. All database specific flows are implemented in the backend using php. All UIs and interactions are done using Javascript. That would really sound perfect to me. Easy coding of controllers written in JS. Easy get/set/update/remove or other useful functions.
Rastin Mehr
Rastin Mehr
February 16 2017 Permalink
@ronimmi Anahita is not a script. It's a graph architecture platform and framework. It can be used for any of the scenarios you have mentioned. Our company's focus is developing apps for science, medicine, and the industry; so building knowledge sharing tools is the main theme. Other tribe member's focus may differ from ours, but they can still use Anahita as the starting point of their projects.

We also want Anahita to be as lightweight as possible. That's why we didn't build Anahita as a product which is often specialized for a specific target market. We certainly aren't interested in building the next Facebook or Twitter.

I agree some apps are missing such as private messaging, videos, etc. but that's not the focus on this article. This article is about the version 4.4 goals. If you are interested in business and product development aspects of Anahita, please feel free to start a topic in the Startup Hub or The Lounge groups.

@imani it's true. I'm still not sure about the easy coding. A lot of more sophisticated UI behaviours that we wanted to have need to be implemented and need to think about API calls that we haven't had until now such as list of available toolbars and commands and suggestion lists for mentions, hashtags, locations, etc.
Nick Swinford
Nick Swinford
February 21 2017 Permalink
@Rastin, one of the main concerns I keep coming back to when I'm thinking about this is overriding views. One of the great parts of Anahita is the ability to override layouts and templates easily. How will that work when we're rendering everything in the frontend?

If we go with #ReactJS, I'd imagine we'd build with Webpack, could we provide some option to override the default Anahita React Components with custom ones?

While it'll be great to render everything in the frontend and rely on Anahita solely as an API, we'll still need a rendering engine to handle emails.
2 people liked this
Rastin Mehr
Rastin Mehr
February 22 2017 Permalink
Yes we still want to be able to override layouts except this time instead of overriding php files it will be js components containing JSX code
Rastin Mehr
Rastin Mehr
February 22 2017 Permalink
We won't entirely remove the html rendering on the server side. We still need to render search engine friendly pages for static pages, actor profiles, and node detailed views.
Scott Crawford
Scott Crawford
February 22 2017 Permalink
Is it correct to have the impression things might get a little more complex as a result of implementing some of these technologies? And, is the net benefit going to be improved rendering speed? Or more along the lines of improved rendering flexibility?
Nick Swinford
Nick Swinford
February 22 2017 Permalink
We should look into server side rendering for react components.

This might require a server with Node as well as one with PHP.
Rastin Mehr
Rastin Mehr
February 22 2017 Permalink
@scott the server side will be more simplified, because currently a lot of what server side is does is elaborate ways to construct all the UI elements in one dispatch call. In the new Architecture the server side has to only create good json data structures.

On the client side we want to have more complex behaviours. JQuery is good at animating DOM elements and doing ajax calls. It isn't good at constructing html code and updating the user interface state when data is updated. As for rendering speed, we don't know yet. It maybe the same or faster. The point is using better tools for building more complex UI behaviours.
Unkown Person liked this
Rastin Mehr
Rastin Mehr
February 22 2017 Permalink
@nicholasjohn16 React server side rendering is good for NodeJS apps, because they can choose to whether render a particular component on the server or client side while reusing the same code. In our case php will do just fine for server side rendering.
James Imani
James Imani
April 26 2017 Permalink
Wanted to share this design with you:

It has good ideas to implement the UX also for Anahita.
Rastin Mehr liked this
Rastin Mehr
Rastin Mehr
April 27 2017 Permalink
That's a very good example, thank you!
James Imani liked this

Additional Information


    Powered by Anahita